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SECTION  1 


INTRODUCTION  AND  SUMMARY 


1.0  PURPOSE  AND  ORGANIZATION  OF  THE  REPORT 

This  report  describes  the  results  of  the  System  Control  for  the  Transitional 
Defense  Communications  System  (DCS)  study.  This  study  defines  the 
functional  characteristics  of  an  automated  system  which  will  provide  the 
information  collection  and  utilization  capabilities  needed  by  the  theatre 
level  in  the  performance  of  its  real-time  mission  and  the  relationship  of 
this  system  to  lower-level  control  systems.  This  is  the  fourth  technical 
report  for  this  study  containing  a  summary  of  the  entire  effort,  the  results 
of  hardware /software  size  and  cost  estimating  activities,  and  an  analysis 
of  the  impact  of  the  recommended  system  on  manpower  requirements. 

Report  1  in  this  study  (Reference  1)  establishes  the  assumed  characteristics 
of  the  DCS  in  the  mid  1980's.  Report  2  (Reference  2)  discusses  the  infor¬ 
mation  collection,  data  base  organization,  and  display  recommendations  for 
system  control.  Report  3  (Reference  3)  discusses  control  actions  which  can 
be  taken  and  algorithms  for  their  implementation.  The  majority  of  Report  3 
is  a  presentation  of  an  algorithm  for  performing  automatic  searches  for 
altroutes  in  the  data  base  developed  in  Report  2.  Other  algorithms  presented 
involve  controlling  the  routing  in  the  AUTOVON  system. 

( 
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The  remainder  of  this  section  describes  the  baseline  assumptions  made 
about  operational  philosophy  and  subsystem  deployment.  A  top-level  over¬ 
view  of  the  recommended  system,  along  with  its  costs  and  benefits,  is 
presented.  This  section  concludes  with  recommendations  of  future  studies 
in  the  system  control  area. 

Section  2  provides  a  summary  of  the  recommendations  relating  to  control  of 
transmission  resources  including  collection  of  parameters,  data  base  and 
display  design,  and  automatic  altroute  searching  algorithms. 

Section  3  is  the  summary  of  controls  for  the  European  automatic  voice 
operated  network  (AUTOVON)  circuit  switched  network. 

Section  4  contains  the  results  of  the  final  design  tasks  of  the  study.  It 
describes  the  implementation  of  controls  and  provides  cost  and  size  estimates 
for  the  entire  recommended  system  control  subsystem,  including  both 
parameter  collection  and  control  activation  portions. 

There  are  three  appendices  in  this  report.  Appendix  A  presents  some 
representative  examples  of  altroute  search  algorithm  execution.  These 
examples  were  created  in  order  to  estimate  the  time  required  to  perform 
such  a  search.  The  most  complicated  example,  generating  a  restoral  plan 
for  a  complete  failure  of  the  Swingate-Houtem  link,  required  about  nine 
seconds  of  execution  time. 

Appendix  B  contains  the  analysis  of  the  impact  of  the  altroute  searching 
algorithms  and  the  use  of  remotely  controlled  patching  devices  called 
channel  reconfiguration  units  (CRU)  on  manpower  requirements  for  DCS 
operations. 
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Appendix  C  contains  the  detailed  size  estimated  for  the  altroute  search 
algorithm  software. 

1.1  PHILOSOPHY  OF  SYSTEM  CONTROL 

The  underlying  philosophy  in  designing  the  control  system  in  this  study  is 
that  control  will  take  place  at  the  lowest  level  in  the  hierarchy  which  can 
feasibly  perform  it.  When  problems  occur  which  cannot  be  solved  at  any 
level  due  to  coordination  requirements  or  for  wider  system  visibility,  the 
control  responsibility  will  be  moved  to  the  next  higher  level.  In  this 
manner,  problems  "bubble  up"  from  the  lowest  level  to  whatever  level  has 
the  visibility  to  solve  them.  This  philosophy  minimizes  the  involvement 
of  higher  system  control  levels  in  the  routine  operation  of  system  resources 
and  provides  a  more  uniform  distribution  of  control  system  loading  across 
the  levels  of  the  control  hierarchy.  As  a  result,  the  response  is  quicker, 
the  system  survivability  is  enhanced,  and  good  utilization  of  equipment  and 
personnel  is  achieved. 

The  capability  for  real-time  control  is  already  being  developed  for  the 
transmission  system  at  levels  below  theatre.  The  automated  technical 
control  (ATEC)  system  will  provide  these  capabilities  for  the  terrestrial 
transmission  system,  and  defense  satellite  communication  system /control 
segment  (DSCS/CS)  will  provide  them  for  the  satellite  system.  Switched 
networks  basically  have  a  two-level  hierarchy,  consisting  of  the  switches 
themselves  at  the  lower  level  and  the  theatre  control  at  the  higher  level. 
Therefore  the  focus  of  this  study  is  those  functions  which  occur  at  the 
theatre  level  and  modifications  at  the  lower  levels  to  support  those  functions. 
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Because  of  this  philosophy  of  control,  the  control  system  design  addresses 
the  following  areas: 


•  Establishment  of  a  real-time  function  for  world  wide 
on-line  system /area  communications  operations  center 
(WWOLS/ACOC) 

•  Reporting  of  subsystem  parameters  to  the  WWOLS/ACOC 

•  Analysis  of  parameter  consolidation  which  occurs  during 
upward  reporting 

•  Definition  of  controls  requiring  area- wide  visibility 

•  Additional  hardware  or  software  which  will  make  control 
more  effective 

1.2  THE  DEPLOYMENT  MODEL 

1.2.1  Purpose  of  a  Deployment  Model 

A  model  provides  a  typical  subsystem  configuration  of  DCS  equipment.  The 
model  can  then  serve  to  define  the  inter- subsystem  interfaces  of  an  area¬ 
wide  control  system  and  specify  the  parameter  reporting  and  controls  of  the 
WWOLS/ACOC  control  level. 

1.2.2  Transmission  System  Deployment  Model 

The  model  used  is  a  simplified  representation  of  the  European  DCS  back¬ 
bone.  This  representation  is  used  as  opposed  to  some  hypothetical  model 
because  it  provides  all  of  the  DCS  characteristics  of  the  mid- 1 980 's  and  is 


/ 


at  least  as  complex  as  any  DCS  area.  In  addition,  using  a  realistic  model 
brings  some  of  the  DCS  peculiarities  into  the  model  which  might  be  over¬ 
looked  in  a  hypothetical  model  development. 

The  transmission  system  deployment  model  and  the  ATEC  hierarchy  assign¬ 
ments  used  in  this  study  are  presented  in  Figure  1-1.  The  backbone 
connectivity  and  equipment  is  the  state  of  the  European  network  after  the 
DEB  IV  digitization  plan  is  implemented. 

The  details  of  each  link  are  given  in  Figure  1-2.  The  connected  stations, 
link  number,  and  type  of  transmission  radio  are  listed  for  every  link.  The 
transmission  links  are  primarily  microwave  line  of  sight  (LOS)  radio  and 
digital  multiplex  equipment  as  specified  by  the  DRAMA  specifications.  Digital 
tropo  scatter  radios  are  also  present.  Satellite  terminals  are  identified  as 
well  as  the  links  they  support.  The  DSCS  III  satellite  is  assumed  for  all 
satellite  links.  The  mileage  of  the  links  are  stated  along  each  link,  and  the 
layout  of  the  network  gives  a  rough  geographical  view  of  the  deployment. 
Finally,  the  links  of  the  European  theater  to  the  Continental  United  States 
(CONUS)  are  identified  in  order  to  show  inter-area  linking  requirements. 

1.2.3  Common  User  Network  Deployment 

The  common  user  switched  networks  modeled  for  this  study  were  assumed 
to  have  the  following  characteristics: 

•  Data  and  narrative /message  traffic  are  carried  over  an 
automatic  data  interchange  network  (AUTODIN  II)  system 
consisting  of  three  packet  switching  nodes,  identical  to  those 
being  developed  for  CONUS,  replacing  the  current  AUTODIN  I 
switches. 
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Transmission  System  Deployment  Model 


Link  Detail 
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•  Voice  traffic  is  carried  over  an  integrated  AUTOVON/ 
AUTOSEVOCOM  II  system  using  AN/TTC-39  switches,  to 
replace  the  current  490L  switches,  and  SB-3865  switchboards. 

Congressional  action  during  the  course  of  the  study  has  made  the  voice 
network  assumption  inappropriate.  Therefore,  the  later  portions  of  the 
study  assumed  that  the  current  AUTOVON  system  would  remain  in  place, 
except  for  the  removal  of  the  Mt.  Pateris  switch  and  modifying  the  trunking 
to  be  consistant  with  the  automatic  secure  voice  communication  network 
(AUTOSEVOCOM  II)  plans. 

Figure  1-3  shows  the  resulting  deployment  of  switches  and  trunks. 

1.2.4  Pre-Existing  System  Control  Components 

ATEC,  as  specified  by  the  ATEC  10000  specification,  is  assumed  to  be 
operational  and  fully  deployed.  All  sites  are  assumed  to  be  suitably  instru¬ 
mented  with  measurement  acquisition  subsystem  (MAS)  components  to 
perform  their  monitoring  function.  Appropriate  higher  level  nodal  control 
subsystems  (NCS)  and  sector  control  subsystems  (SCS)  are  also  assumed 
to  be  deployed,  resulting  in  a  comprehensive  performance  monitoring  and 
stress  isolation  system  for  the  terrestrial  transmission  system. 

The  satellite  system  is  assumed  to  be  under  the  control  of  its  own  control 
segment,  as  specified  by  the  DSCS/CS  specifications.  Detailed  control  of 
earth  terminal  operation  is  performed  by  the  terminal  control  element 
(TCE)  while  network-wide  operations  are  controlled  by  the  network  control 
element  (NCE).  One  difference  between  the  DSCS/CS  specification  and  our 
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recommendation  is  that  we  recommend  integrating  the  operational  control 
element  (OCE)  into  the  theatre  level  control  function  because  its  primary 
function  is  to  be  an  intelligent  terminal  accessing  the  NCEs.  This  function 
could  be  performed  by  the  recommended  ACOC  system  without  separate 
OCE  hardware.  The  OCE  therefore  does  not  exist  as  a  separate  entity  in 
this  study. 

1.3  CONTROL  SYSTEM  OVERVIEW 

1.3.1  The  Control  System  Hierarchy 

The  hierarchical  relationships  and  telemetry  interfaces  between  the  DCS 
subsystems  are  shown  in  Figure  1-4.  The  top  level  of  control  is  the  defense 
communications  agency  operation  center  (DCAOC),  where  world-wide  control 
of  the  DCS  is  exercised.  Associated  with  DCAOC  is  the  AUTODIN  II  network 
control  center  (NCC)  which  is  responsible  for  world-wide  control  of  the 
AUTODIN  II  network.  A  similar  structure  is  present  at  the  theatre  level, 
with  an  ACOC  exercising  control  over  theatre  wide  operations  and  an 
AUTODIN  II  subnetwork  control  center  (SNCC)  reporting  to  it.  The  SNCC 
also  reports  to  the  NCC,  and  ACOC  reports  to  DCAOC  for  management  and 
long-term  engineering  purposes.  Lower  levels  report  to  the  ACOC,  with 
AUTODIN  II  switches  reporting  via  the  SNCC  and  DSCS,  and  ATEC  and 
AUTOVON  reporting  directly  to  ACOC,  AUTOVON  uses  the  ATEC  telemetry 
system  for  reporting,  but  the  ATEC  system  provides  only  communication 
service  and  performs  no  AUTOVON  control  function. 
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Figure  1-4.  The  Control  Subsystem  Hierarchy 


A  summary  of  the  area-wide  information  flow  recommended  in  this  study 
is  presented  in  Figure  1-5.  This  figure  expands  upon  the  hierarchy  of 
Figure  1-4  and  identifies  the  interfaces  which  make  up  the  area-wide  control 
system  design.  The  left  side  of  the  figure  details  the  subsystems  which  are 
present  or  planned  for  integration:  AUTOVON,  AUTODIN  II,  ATEC  and 
DSCS/CS.  Recommended  additions  to  this  subsystem  hierarchy  are  the 
SNCC  for  AUTODIN,  the  rapid  access  maintenance  monitor  (RAMM)  of 
AUTOVON  and  the  CRU  for  ATEC  stations.  The  right  side  of  the  figure 
describes  the  recommended  control  functions  of  the  real-time  WWOLS/ 
ACOC.  The  control  functions  listed  under  each  control  level  identify  the 
functions  of  that  level  in  the  area-wide  control  system.  For  the  existing  or 
planned  subsystems,  these  functions  are  a  combination  of  some  previously 
defined  subsystem  functions  and  new  functions  required  to  support  area-wide 
control. 

The  primary  addition  recommended  by  this  study  is  a  real-time  WWOLS/ 
ACOC  function.  The  ACOC  performs  controls  requiring  area-wide  visibility. 
It  also  acts  as  a  central  storage  and  access  area  for  performance  parameter 
history  required  in  planning  and  assessment. 

Transmission  control  will  be  implemented  with  CRUs.  These  elements 
of  the  transmission  system  will  enable  time-division  patching  among 
channels  of  any  group  or  link  entering  a  DCS  station.  The  CRU  eliminates 
the  need  for  all  levels  of  multiplexer  in  order  to  patch  a  channel  to  a 
different  multiplex  group.  The  CRU  has  local  control  capability  via  a 
keyboard /display  unit  and  can  be  remotely  controlled  by  higher  control 
levels  via  its  ATEC  communications  interface  subsystem  (CIS)  interface. 


Figure  1-5.  System  Control  Information  Plan 


The  only  addition  to  the  AUTODIN  II  subsystem  for  implementation  of 
area-wide  control  is  the  SNCC.  This  control  element  is  identical  in  both 
function  and  implementation  to  the  CONUS  NCC,  except  that  it  deals  only 
with  the  European  theatre  of  the  AUTODIN  II  network.  The  reasons  for  the 
addition  of  this  element  are  the  following: 

•  It  provides  the  AUTODIN  II  NCC  function  in  the  theatre  in  case 
of  loss  of  CONUS  NCC  or  the  links  to  CONUS. 

•  It  provides  AUTODIN  II  reporting  to  ACOC  without  trans- 
Atlantic  communication  from  the  CONUS  NCC. 

•  It  allows  implementation  of  AUTODIN  II  control  using  an 
existing  system  design. 

The  SNCC  will  be  the  destination  of  reports  from  European  packet  switching 
nodes  (PSNs),  which  will  then  retransmit  reports  to  the  NCC  in  CONUS. 

1.3.2  Overview  of  AUTOVON  Control 

AUTOVON  control  ensures  that  the  network  carries  critical  subscriber 
traffic  to  the  best  of  its  ability.  This  does  not  necessarily  mean  optimizing 
the  network  grade  of  service  (GOS),  but  it  does  mean  at  least  the  following: 

•  Providing  switch  routes  between  all  sources  and  destinations 
which  have  physical  connectivity. 

•  Preventing  the  network  from  traffic  overloads  of  such  a 
magnitude  that  increasing  the  offered  traffic  load  results  in 
a  decrease  in  the  carried  load. 


•  Providing  management  visibility  to  determine  the  proper 
real-time  control  actions  and  to  monitor  the  longer  term 
performance  of  the  system. 

Visibility  of  network  status  is  obtained  by  collecting  parameters  from  the 
switch  and  providing  them  in  a  useful  manner  at  ACOC.  The  TTC-39  switches 
specified  for  AUTOSEVOCOM  II  had  extensive  reporting  capabilities  designed 
into  them  and  were  adequate  without  significant  modification.  For  the  490L 
switch,  an  external  device  must  be  used  to  sense  the  switch  status.  This 
function  can  be  performed  by  the  RAMM  which  is  currently  being  deployed. 

New  software  and  communications  interfaces  to  the  RAMM  are  required  in 
order  for  it  to  fulfill  these  functions  as  described  in  Section  4. 

The  parameters  recommended  for  AUTOVON  control  provide  for  compre¬ 
hensive  status  of  the  network  equipment  and  estimators  of  trunk  and  switch 
traffic.  Detailed  traffic  data  needs  to  be  compiled  for  long-term  engineering 
purposes,  but  the  required  smoothing  time  makes  such  data  unusable  for 
real-time  control.  Control  can  be  achieved  without  such  detail. 

To  provide  these  parameters  to  a  controller  in  a  useful  fashion,  a  data  base 
and  a  hierarchical  set  of  displays  are  provided.  By  using  this  technique, 
large  amounts  of  data  can  be  made  available  to  the  controller,  and  he  need  only 
examine  the  data  pertinent  to  the  current  problem.  The  hierarchical  displays 
present  a  concise  summary  of  system  status  at  the  top  display  level  and 
progressively  more  detailed  displays  as  the  controller  goes  deeper  into  the 
hierarchy.  This  prevents  overloading  the  controller  with  unrelated,  needless 
information.  Another  design  principle  used  to  reduce  operator  workload  is  to 
identify  abnormal  or  changed  data  on  the  displays  rather  than  just  displaying 
raw  status  parameters. 


Controls  which  are  easily  implemented  from  the  theatre  level  are  those 
which  modify  the  switch  memory.  The  switch  memory  can  be  modified  via 
the  RAMM,  without  any  modifications  to  the  switch  itself.  It  is  recommended 
that  the  theatre  level  controller  be  provided  with  a  flexible  facility  for  chang¬ 
ing  the  switch  routing  tables  based  on  this  capability.  Two  automatic 
algorithms  which  modify  routine  tables  are  also  recommended. 

The  first  algorithm  is  a  simple  form  of  adaptive  routing.  In  order  to  limit 
the  amount  of  time  a  call  can  occupy  switch  equipment  and  to  prevent  the 
use  of  extremely  inefficient  routes,  AUTOVON  switches  are  restricted  to 
between  one  and  four  alternate  route  choice's.  This  leads  to  the  possibility 
that  all  the  route  choices  allowed  by  the  routing  tables  could  be  in  a  failed 
condition  while  some  other  route,  although  less  efficient,  is  still  functioning. 
The  recommended  adaptive  routing  simply  modifies  the  routing  tables  in 
response  to  trunk  group  failures  in  order  to  provide  functioning  routes  to  all 
destinations  as  long  as  any  connectivity  is  functioning.  The  other 
recommended  algorithm  provides  a  form  of  overload  protection.  It  senses 
the  loading  on  a  trunk  group  over  a  short  interval.  If  the  trunk  group  was 
heavily  loaded  during  that  interval,  all  secondary  and  tertiary  routes  which 
contain  that  group  are  inhibited  during  the  next  interval.  This  tends  to 
reserve  the  group  for  those  calls  which  can  most  efficiently  use  it;  and 
most  importantly,  it  reduces  the  time  that  switches  throughout  the  network 
are  tied  up  processing  secondary  and  tertiary  routed  calls  which  will  most 
likely  be  blocked  anyway. 
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1.3.3  Cos  t  Summar 


Budgetary  costs  for  the  hardware  and  software  modifications  or  additions 
derived  during  this  study  are  summarized  in  Table  1-1.  Hardware  costs  for 
the  additions  to  the  RAMM  and  the  ACOC/WWOLS  system  control  processor 
are  representative  catalog  prices  for  state-of-the-art  hardware  available 
off-the-shelf.  The  cost  basis  for  the  CRU  is  given  in  Section  4.2. 1.2.  The 
budgetary  software  costs  include  design,  code,  debug,  and  software 
documentation.  The  documentation  is  assumed  to  consist  of  Software 
Specifications  Parts  I  and  II,  test  plans,  and  user's  manuals.  Higher  order 
language  (HOL)  software  is  estimated  at  six  lines  of  code/day.  Assembly 
level  language  is  estimated  at  12  lines  of  code/day. 


TABLE  1-1.  BUDGETARY  COST  SUMMARY 


Sys  tem  /Subsys  tem 

Hardware  Costs 
(Dollars) 

Software  Costs 
(Man-Days) 

AUTODIN  II  SNCC 

5 

RAMM 

42,210* 

178 

CRU 

2,830, 510** 

-- 

DSCS  TCE 

40 

DSCS  NCE 

35 

AT  EC  CIS 

5 

AT  EC  NCS 

46 

AT  EC  SCS 

40 

ACOC/WWOLS 

93,065 

3338 

See  Section  4. 2. 2. 3 
See  Section  4. 2 . 1 . 2 


1.4  CONNECTIVITY  CONTROL  BENEFITS 


One  goal  of  connectivity  control  is  to  improve  the  circuit  availability  to  a 
user  under  conditions  of  equipment  degradation  or  failure.  This  study 
recommends  that  an  automated  altroute  search  algorithm  at  ACOC  be 
implemented  in  order  to  reach  this  goal.  The  benefits  of  this  control  are 
measured  in  terms  of  a  circuit  availability  analysis  comparing  the  algorithm's 
altr outing  versus  current  practices. 

In  the  analysis  in  Report  3,  some  typical  circuit  routes  were  postulated 
and  altroutes  were  characterized  for  these  routes.  The  resulting  circuit 
outage  probability  (in  percent  of  time  out)  is  plotted  as  a  function  of  a  circuit's 
priority  in  Figure  1-6. 

The  comparison  of  primary  interest  is  between  the  manual  search /manual 
patch  altrouting  versus  the  algorithm  search /manual  patch  altroute  imple¬ 
mentation.  The  algorithm  reduces  outage  probability  considerably  due  to 
its  rapid  altroute  synthesis.  The  manual  altroute  search  method  employs 
the  current  system  of  searching  for  an  altroute  from  multiplexer  maps  and 
coordinating  the  result  with  other  stations  involved  over  voice  or  teletype 
(TTY)  orderwire  circuits. 

Figure  1-6  also  makes  a  comparison  of  these  two  altroute  methods  versus 
altrouting  using  a  CRU  at  the  patching  stations.  This  CRU  can  receive 
automatically  generated  patching  messages  from  ACOC  and  implement  an 
altroute  in  significantly  shorter  time  than  manual  patching.  The  result  is 
reduced  circuit  outage  probability  over  all  priority  levels  of  the  altroute 
group. 
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CIRCUIT  OUTAGE  PROBABILITY 
FOR  CIRCUITS  ALTROUTED 
FROM  A  FAILED  LINK 


KEY: 

— — —  MANUAL  SEARCH/MANUAL  PATCH 
-  —  —  -  AUTO  SEARCH/MANUAL  PATCH 


AUTO  SERACH/AUTO  PATCH 


/ 

/ 

> 


II  II _ I - 1 - 1 - 1 - 1 - 1 

10  20  30  40  SO  60  70  10  90  100 

RP  RANKING  OF  A  CIRCUIT  ON  A  FAILED  LINK  BEING  ALTROUTED 

Figure  1-6.  Availability  vs  Altroute  Priority 
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Using  central  altroute  control  which  has  the  current  status  of  the  network 
can  significantly  improve  circuit  availability  by  automating  the  search  for 
alternate  routes  and  removing  the  time-consuming  human  factors  in  the 
current  system. 

1.5  FUTURE  STUDIES 

During  the  course  of  this  study,  we  identified  several  promising  areas  for 
further  research.  The  primary  candidate  would  be  to  demonstrate  the 
automatic  altrouting  algorithms  described  in  Reference  3. 

This  study  has  proposed  algorithms  which  can  be  used  to  automate  the 
altroute  search  control.  The  benefits  of  the  use  of  these  algorithms  at  the 
area  level  have  been  estimated.  The  estimates  show  improved  service 
availability  and  possible  manning  reductions  at  stations  in  the  DCS.  The 
next  logical  step  for  this  work  is  the  computer  programming  of  the  algorithms 
presented  in  this  study.  The  actual  availability  improvements  that  the 
algorithms  can  provide  can  then  be  analyzed  for  a  variety  of  real  network 
conditions.  Only  with  the  programmed  version  of  the  algorithms  can  this 
analysis  be  carried  out  for  the  statistically  significant  number  of  examples 
needed  to  prove  the  algorithm's  benefits. 

This  task  of  implementing  the  altroute  algorithms  should  cover  all  of  the 
related  subtasks  in  order  to  result  in  a  final  usable  program  package.  The 
subtasks  that  should  be  completed  as  part  of  this  task  are: 

•  Establish  the  DCS  data  base  for  the  European  theatre.  This 
data  base  will  be  needed  in  order  to  actually  work  realistic 
examples  of  the  finished  product. 
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•  Program  the  actual  altrouting  algorithms:  the  main  calling 
routines,  search  routines,  goal  station  definition  routine,  and 
the  cost  and  heuristic  cost  calculating  routines, 

•  Implement  the  patching  displays  which  convey  the  altroute 
plans  to  the  area  controller  and  patching  controllers. 

•  Test  the  program  package  extensively  over  a  wide  variety  of 
altroute  problems  to  determine  the  package's  effectiveness  to 
provide  service  availability  improvement. 

The  recommended  system  control  depends  heavily  on  AT  EC  telemetry,  both 
for  collection  of  parameters  and  for  the  dissemination  of  control  commands. 
The  survivability  of  the  currently  planned  ATEC  telemetry  system  is  very 
limited  due  to  its  strict  hierarchical  structure.  A  study  needs  to  be  made 
to  design  a  robust  telemetry  system  for  ATEC  which  can  be  fitted  into  the 
system  without  major  changes  to  either  the  ATEC  hardware  or  its  concept  of 
operations. 

Another  area  which  needs  considerable  research  is  the  thrashing  phenomenon 
in  circuit  switched  networks.  The  basic  cause  and  effect  relationship  between 
switch  overload  and  decreased  traffic  handling  ability  is  understood,  and 
control  actions  have  been  heuristically  defined  which  can  contain  the  problem. 
However,  there  are  several  aspects  of  the  problem  which  simply  are  not 
known. 

Research  is  needed  to  determine  if  there  is  a  bound  on  the  region  of  network 
thrashing  to  determine  if  a  thrashing- proof  network  can  exist. 


Heuristically,  it  seems  that  there  is  surely  such  a  bound.  With  the  rapidly 
decreasing  cost  of  switch  processing  capability,  it  may  be  practical  in  the 
future  to  design  networks  so  that  thrashing  cannot  occur.  This  research 
should  include  a  study  of  the  impact  of  different  signalling  and  route  searching 
protocols  on  the  bound  in  order  to  provide  guidance  for  future  network  designs. 

Another  aspect  of  the  thrashing  problem  is  to  study  the  transient  behavior 
of  network  thrashing.  It  appears  that  the  approach  to  a  thrashing  condition 
can  occupy  a  significant  time  span,  especially  if  the  heuristically  designed 
controls  are  employed  in  an  attempt  to  prevent  thrashing.  Further,  when 
the  traffic  load  is  reduced,  the  network  does  not  return  to  normal  immediately 
but  stays  in  a  reduced  capacity  state  for  some  time  after  which  the  network 
spontaneously  switches  to  the  normal  state.  The  factors  which  affect  this 
transient  behavior  are  not  understood.  An  understanding  of  these  factors 
would  provide  guidance  toward  designing  traffic  controls  for  old  networks 
and  signalling/routing  protocols  for  new  networks. 

Relative  to  old  networks,  two  traffic  control  algorithms  were  recommended 
but  not  tested  during  this  study.  If  the  490L  network  is  going  to  continue 
in  use,  these  algorithms  should  be  tested  by  accurate  traffic  modelling  and/ 
or  simulation.  It  is  heuristically  clear  that  these  algorithms  will  signifi¬ 
cantly  increase  the  capability  of  the  network  under  stress  conditions,  but  we 
were  unable  to  demonstrate  exactly  how  much  within  the  scope  of  this  study. 

The  last  item  relative  to  AUTOVON  which  needs  further  study  is  the  RAMM. 
Several  functions  have  been  attributed  to  the  RAMM  on  the  basis  of  fairly 
vague  documentation  and  a  couple  of  clarifying  telephone  conversations  with 
RAMM’s  developers.  A  detailed  study  of  the  RAMM  design,  its  interface 


with  the  490L  switch,  and  how  RAMM  fits  with  future  plans  for  the  490L 
system  needs  to  be  undertaken  to  define  in  detail  what  role  the  RAMM  can 
plan  in  the  system  control. 

In  the  analysis  of  manpower  and  response  time,  we  ran  into  the  problem 
that  the  available  data  is  based  on  the  pre-ATEC,  pre-DEB  DCS.  Other 
studies  available  to  us  extrapolated  this  data  so  that  we  were  able  to  draw 
some  conclusions.  However,  when  ATEC  and  DEB  are  fully  operational, 
the  network  operating  characteristics  will  be  radically  changed  from  the 
last  observations  that  were  actually  made.  As  these  subsystems  are 
introduced,  careful  accounting  can  be  done  by  either  time  reporting  or 
observation,  but  studies  should  be  done  on  a  regular  basis.  These  studies 
will  allow  the  refinement  of  manpower  prediction  models  and  will  permit 
the  identification  of  fruitful  areas  for  further  automation  or  other  engineering 
action. 
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SECTION  2 


TRANSMISSION  SYSTEM  CONTROL 

2.  0  CONTROL  SYSTEM  OVERVIEW 

This  section  summarizes  the  transmission  control  elements  that  have  been 
recommended  in  the  previous  reports  of  this  study.  The  transmission  con¬ 
trol  system  consists  of  the  following  subsystems: 

•  ATEC 

•  DSCS/CS 

•  ACOC/WWOLS 

Of  these  subsystems,  the  real-time  WWOLS  function  is  the  element  pri¬ 
marily  discussed  in  this  study.  The  other  elements  of  the  network  control 
are  already  planned  and  are  fairly  self-contained  in  their  functions.  The 
interfacing  of  these  elements  to  ACOC/WWOLS  is  the  focus  of  this  study. 
Therefore,  this  summary  will  deal  with  these  new  control  interfaces  to 
ACOC. 

Figure  2-1  is  a  matrix  of  interfaces  versus  existing  subsystems.  The 
transmission  subsystem  elements  are  listed  as  one  axis  of  the  matrix. 

The  elements  of  control  system  definition  are  the  other  matrix  axis. 

These  elements  are  the  following: 

•  Parameter  collection- -the  network  parameters  that  are  of 
use  for  controls  originating  at  or  planning  at  ACOC. 
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•  Parameter  communication- -communication  path,  message  rate. 

•  Parameter  analysis- -processing  performed  on  the  data  by  ACOC. 

•  Control  implementation--selection  and  physical  actuation  of 
controls . 

The  crosses  on  the  matrix  of  Figure  2-1  define  those  control  subsystems 
which  are  involved  in  each  element  of  the  control  system  designed  in  this 
study.  The  matrix  intersections  also  define  sections  of  discussion  to 
follow  which  define  the  control  system. 

2.1  PARAMETER  COLLECTION 

2.1.1  ATEC  Parameters 

The  ATEC  subsystem  in  the  mid- 1980's  DCS  will  be  the  primary  source 
of  parameters  for  the  terrestrial  portion  of  the  DCS  network.  The 
categories  of  parameters  that  are  useful  to  ACOC  from  this  subsystem 
and  the  reason  for  the  need  is  summarized  below: 

•  Equipment  status  information- -allows  ACOC  to  be  aware 
of  the  state  Of  the  transmission  facilities  that  may  be  used 
in  creating  altroutes. 

•  Fault  isolation  information- -brings  failed  network  services 

to  ACOC  visibility  so  that  ACOC  can  aid  in  altroute  generation. 
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•  Connectivity  updates- -provide  ACOC  wit  current  routes 
for  circuits  or  trunks.  Needed  for  route  planning  and 
administration. 

•  310-55-1  "Q-line"  data--station  measurements  which  can 
be  used  historically  to  evaluate  DCS  transmission  system 
performance. 

Figure  2-2  cross-references  these  parameter  categories  for  ACOC  visibility 
with  the  ATEC  parameters  to  fulfill  the  needs  of  ACOC.  The  parameters 
selected  in  Figure  2-2  originate  at  the  station  level  of  ATEC  in  the  MAS  units. 
The  first  four  parameters  are  direct  results  of  hourly  MAS  measurements 
which  are  logged  into  history  files  at  node  and  sector.  These  history  files 
of  parameters  can  be  trended  by  mean  and  standard  deviation  over  various 
time  periods.  ATEC  can  store  these  histories  for  up  to  a  month.  Thus, 
these  first  four  parameters'  summaries  should  be  sent  to  ACOC  on  at  least 
a  monthly  basis  as  quality  control  summary  data. 

The  last  four  parameters  listed  in  Figure  2-2  are  related  and  have  to  do 
with  status  monitoring  of  the  transmission  system.  The  fault  isolation 
activity  is  an  inter-level  cooperative  activity  of  ATEC  to  determine  the 
exact  location  of  alarms  or  out-of-tolerance  equipment  reported  via  the 
quality  control  sequences  or  equipment  alarm  monitoring.  The  fault 
isolations  give  the  ACOC  control  the  data  needed  to  begin  altroute  search¬ 
ing.  The  alarm  and  monitoring  parameters  from  ATEC  are  less  refined 
parameters  but  provide  the  ACOC  data  base  with  current  status  infor¬ 
mation  on  possible  preemptable  segments  in  the  network.  ATEC  data  base 
maintenance  provides  ACOC  with  current  connectivity  data  to  show  how 
the  transmission  medium  is  used  for  specific  services.  The  timeliness 
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ACOC  Parameter  Catagories 


Mean  &  lowest  RSL  history  (TDM  system' 

(3.2. 1.1.4)*  _ 


Baseband  degradation  history  (TDM  sys- 
tem)  (3.2. 1.1.4) _ 

Time  duration  history  of  all  multiplex 
levels  degradations  (TDM  systems) 

(3.2. 1.1. 4) _ 


Radio  transmitter  power  data  history 

(3. 2. 1.2.5) _ 


Fault  isolation  reports  (3.2. 1.2.4) 


Automatic  quality  control  test  seq¬ 
uences  (3.2. 1.3) 


Equipment  and  facility  alarm  monitoring 
(3.2.14) _ 


Data  base  management  (3.2.1.12.5) 


♦Refers  to  ATEC  10000  specification  sections. 


Figure  2-2.  ACOC  Parameter  Needs  vs  ATEC  Data 
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of  the  ACOC  data  base  is  crucial  to  its  altroute  and  normalization  control 
activities  and  system  administration. 

2.1.2  DSCS/CS  Parameters 

The  DSCS  control  system  will  provide  the  needed  parameters  for  manage¬ 
ment  of  the  satellite  portion  of  the  DCS.  The  four  parameter  categories 
defined  in  Section  2.1.1  for  the  ATEC  parameters  apply  to  DSCS  parameters 
as  well  since  the  ACOC  function  is  the  same  for  all  transmission  segments 
in  the  DCS. 

The  method  of  correlating  the  ACOC  parameter  categories  with  the  actual 
parameters  available  from  DSCS/CS  is  done  with  the  cross-reference  of 
Figure  2-3.  The  parameters  chosen  from  the  full  DSCS/CS  parameter  list 
(Report  2,  Section  5.4)  were  selected  because  they  primarily  deal  with  the 
service-oriented  view  of  the  ACOC  mission.  They  report  the  status  and 
availability  on  a  go/no-go  basis.  ACOC  must  provide  service  to  users 
over  the  DCS  facilities.  The  details  of  the  transmission  facility  state  are 
not  important  to  real-time  control,  only  the  availability  for  use  right  now. 
The  only  need  for  specific  equipment  status  data  is  the  historical  need 
to  see  how  the  network  is  functioning  over  time  in  an  effort  to  aid  in 
planning  and  assessment. 

The  first  three  parameters  selected  from  DSCS/CS  are  basically  summary 
items.  They  give  status  data  which  is  condensed  from  more  specific 
parameter  reports  within  the  DSCS/CS.  These  parameters  will  be  the 
primary  source  of  go/no-go  data  for  ACOC  from  which  data  base  status 
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Figure  2-3.  ACOC  Parameter  Needs  vs  DCSC/CS  Data 
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updates  are  made.  In  addition,  these  parameters  can  be  used  within  ATEC 
to  aid  in  fault  isolation  when  a  route  passes  over  a  satellite  link. 

The  configuration  updates  supplied  by  the  DSCS/CS  will  provide  ACOC  with 
current  connectivity  data  for  the  subset  of  the  total  DCS  network  which  is 
satellite  links.  Spare  resource  data  will  give  current  capacity  data  con¬ 
cerning  the  satellite  links.  Both  items  are  needed  for  route  planning  over 
DSCS  links. 

The  remaining  parameters  are  generally  calibration  test  data.  They  will 
be  used  at  ACOC  to  study  equipment  performance  in  a  historical  way  for 
planning  and  assessment  purposes.  Calibration  test  data  is  utilized  by 
DSCS/CS  elements  on  a  real-time  basis  for  control  and  management  of 
satellite  operations.  The  parameters  selected  for  use  at  ACOC  are  chosen 
to  reflect  system  performance  rather  than  site  performance.  The  NCE 
should  be  the  point  where  the  data  is  collected  and  held  for  transmission  to 
ACOC. 

2.2  PARAMETER  COMMUNICATION 

2.2.1  ATEC  Parameter  Communication 

2.2. 1.1  The  Physical  Communication  Links --The  ATEC  communication 
system  is  clearly  defined  in  Reference  4  (ATEC  10000),  The  primary 
links  (ACOC,  sector,  node,  station)  are  2400  bits  per  second  (BPS),  full 
duplex,  dedicated  links  between  control  levels  in  ATEC  (see  Figure  2-4). 
Stations  at  MAS  sites  will  communicate  with  one  another  over  150  baud 
dedicated  links.  The  ACOC  system  design  will  have  a  2400  BPS  AUTODIN  II 
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access  line  to  be  used  to  connect  ACOC  with  each  sector.  Using  AUTODIN  II 
rather  than  dedicated  sector  ports  will  guarantee  the  use  of  redundant  and 
adaptive  routing  of  messages  in  either  direction.  The  message  format  for 
the  ATEC  links  is  given  in  Figure  2-5.  For  consistency,  the  messages 
between  ACOC  and  ATEC  should  be  sent  with  the  ATEC  message  format 
embedded  within  the  AUTODIN  II  format.  This  would  allow  the  messages  of 
lower  ATEC  levels  to  be  transmitted  to  ACOC  via  sector  without  format 
changes  and  vice  versa. 

2.2. 1.2  The  Message  Rates  for  ATEC  Parameter  Reporting- -The  messages 
required  from  ATEC  over  the  channels  to  ACOC  fall  into  two  classes: 

•  Immediate  update  messages 

•  Historical  parameter  transfer  messages 

In  the  first  class,  the  critical  item  is  the  bit  rate  required  under  stress 
conditions  of  known  message  quantity  and  time  limitations.  The  second 
class  of  messages  has  no  short-term  time  limit  for  transmission.  The 
critical  parameter  is  the  total  character  count  in  the  messages,  to  determine 
the  light  load  transmission  and  processing  time.  The  last  four  parameters 
of  Figure  2-2  fall  into  the  first  class;  the  first  four  parameters  are  in  the 
second  class. 

Immediate  update  messages  include  data  base  updates,  equipment  status, 
and  fault  isolation  parameters.  These  parameters  yield  real-time  control 
actions.  Thus,  these  parameters  must  be  timely  and  messages  must  be 
sent  to  ACOC  on  parameter  change. 
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Figure  2-5.  The  ATEC  Message  Format 
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An  analysis  was  made  in  Report  2  (Section  3.2.2)  to  estimate  the  message 
reporting  load  of  these  messages.  This  analysis  takes  the  ATE C  10000 
specification  MAS  reporting  load  as  a  starting  point.  The  messages  are 
assumed  to  be  reported  up  the  ATEC  control  hierarchy  and  are  consolidated 
as  they  proceed.  Assumptions  are  made  as  to  the  report  consolidation  at 
each  level  in  Report  2.  The  result  of  the  analysis  is  that  an  estimated  195 
BPS  flow  from  the  sectors  to  ACOC  are  required  to  handle  the  update 
messages.  This  estimate  was  made  for  the  European  ACOC  and  results 
in  an  average  of  50  BPS  per  sector.  The  ATEC  10000  specification  sets 
10%  of  the  2400  BPS  sector/ACOC  link  capacity  as  a  design  capacity  for 
messages  under  design  stress.  Since  status  reporting  is  the  primary  function 
of  the  sector/ACOC  message  channel,  there  appears  to  be  more  than  enough 
message  capacity  at  sectors  to  transmit  the  update  parameters  to  ACOC 
from  the  ATEC  hierarchy. 

The  summary  of  routine  transmission  link  tests  makes  up  the  historical 
parameter  class.  Report  2  (Section  5.3)  estimates  the  message  size  per 
summary  as  84  characters  per  link.  With  410  links  in  the  European  ACOC, 
the  character  transfer  of  all  of  the  historical  parameters  to  ACOC  would 
result  in  a  transfer  message  of  138,000  characters.  This  load  may  occur 
daily,  weekly,  or  monthly  depending  on  the  ACOC  historical  requirements 
for  this  data. 

2.2.2  DSCS/CS  Parameter  Communication 

2.2.2. 1  Physical  Communication  Links --Two  new  communication  links 
are  recommended  to  utilize  DSCS  data. 


•  The  NCEs  will  interface  to  WWOLS  via  AUTODIN  II.  Using 
AUTODIN  II  guarantees  that  messages  in  either  direction  will 
use  redundant  and  adaptive  routing. 

•  The  TCEs  will  interface  the  AT  EC  station  over  voice  orderwire 
and  150  BPS  CIS  interfaces.  TCE/CIS  messages  will  be  reported 
in  ATEC  CIS  format  to  provide  the  status  of  DSCS  transmission 
segments  on  a  local  level. 

2.2.2. 2  Message  Rates  for  DSCS/CS  Parameter  Reporting- -The  messages 
sent  to  ACOC  from  the  DSCS/'CS  are  shown  in  Table  2-1.  Those  listed  as 
24-hour  intervals  are  historical  parameters.  The  others  are  required  for 
real-time  control  and  are  reported  on  an  immediate  update  basis. 

Table  2-1  details  the  message  sizes  for  the  DSCS/CS  parameters  to  be 
sent.  The  details  of  the  sizing  are  to  be  found  in  Report  2  (Section  5.4).  In 
order  to  determine  whether  these  parameters  can  be  transmitted  in  real¬ 
time,  a  stress  scenario  like  the  one  adopted  from  the  ATEC  10000  specifica¬ 
tion  was  developed. 

The  stress  scenario  for  DSCS/CS  parameter  message  rate  estimation 
assumes  that  the  following  messages  are  a  message  group  which  must  be 
transmitted  to  ACOC  as  part  of  a  critical  update  for  control: 

•  One  link  performance  assessment  initial  and  follow-up 
report 

•  One  equipment  status  initial  and  follow-up  report 
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TABLE  2-1.  DATA  FLOW,  NCE/WWOL S 


131,401 

Characters/ 


•  One  text  message  elaborating  on  a  failure 

•  One  configuration  report  related  to  a  failure 

This  message  sequence  might  be  caused  by  an  equipment  degradation  which 
caused  a  link  capacity  reduction  and  some  channel  reconfiguration  around 
the  problem.  This  data  would  be  needed  by  ACOC  for  updating  its  data  base 
in  anticipation  of  fault  isolation  reports  from  ATEC  regarding  circuits 
carried  partially  by  the  degraded  satellite  link.  A  reasonable  time  to  require 
this  type  of  information  to  be  available  at  ACOC  is  assumed  to  be  one  minute. 

From  Table  2-1,  the  message  group  consists  of  a  total  of  5754  bits.  To 
transmit  this  group  over  one  minute,  96  BPS  is  needed.  This  bit  rate  is 
well  within  the  9600  baud  capabilities  specified  by  the  DSCS/CS  specifications 
for  the  NCE/OCE  interface. 

The  messages  crossing  TCE/CIS  interface  are  a  subset  of  the  messages 
crossing  the  NCE/ACOC  interface  (see  Table  2-2).  This  information  provides 
ATEC  condensed  status  data  in  order  to  enable  fault  isolation  when  a  trunk 
or  circuit  uses  a  satellite  segment.  The  message  group  of  the  stress 
scenario  presented  earlier  sends  4954  bits  to  the  local  ATEC  station.  To 
meet  the  60- second  time  frame  for  reporting,  82  BPS  transmission  is 
required.  The  TCE/CIS  link  has  a  capacity  of  150  BPS,  which  is  adequate 
for  reporting  of  real-time  updates  to  ATEC  from  a  TCE. 

Historical  parameters  from  DSCS/CS  will  include  the  link  performance 
summary  and  the  calibration  test  data  (see  Table  2-1).  These  parameters 
are  intended  only  for  planning  and  assessing  functions  at  ACOC  and  will  be 
sent  over  the  NCE/ACOC  link.  Table  2-1  shows  the  estimates  for  each 


TABLE  2-2.  DATA  FLOW  TCP/CIS 


summary  of  this  historical  data,  31,290  bits  total.  The  estimation  of  these 
message  sizes  is  based  upon  an  assumption  of  30  satellite  links  under  the 
NCE  control  and  15  satellite  terminals  (see  Report  2,  Section  5.4  for  details). 

2.3  PARAMETER  ANALYSIS 

2.3.1  Data  Base  Maintenance 

The  primary  use  of  parameters  received  from  the  transmission  control 
subsystems  is  the  maintenance  of  the  ACOC  connectivity  data  base.  The 
connectivity  data  base  design  for  the  ACOC  has  been  presented  in  Report  2 
(Section  3.7).  Figure  2-6  summarizes  the  data  base  file  types  and  their 
linking  relationships.  The  status  and  connectivity  updates  provided  by  both 
ATEC  and  DSCS/CS  reports  are  the  raw  data  with  which  the  data  base  is 
kept  current.  The  station,  link,  trunk,  and  circuit  files  in  the  data  base 
are  updated  as  new  connectivity  data  is  received  by  ACOC.  The  ACOC 
software  translates  connectivity  reports  into  changes  in  all  files  in  the  data 
base  which  are  impacted.  Fault  reports  cause  the  ACOC  processor  to 
generate  a  standard  fault  report  file  for  the  data  base.  In  addition,  this 
new  file  is  linked  to  the  station,  link,  trunk,  and  circuit  files  which  the  fault 
impacts. 

The  data  base  update  is  crucial  to  further  analysis  and  control  activities 
which  ACOC  carries  out.  The  displays  from  which  ACOC  personnel  obtain 
network  visibility  are  a  reflection  of  the  data  base  contents.  Circuit  or 
trunk  altrouting  relies  upon  current  connectivity  and  status  data  at  ACOC 
to  search  out  operational  routes. 


Figure  2-6.  Data  Base  File  Linking 


...  -X- 


2.3.2  Altroute  and  Normalization  Job  Queueing 

The  data  required  to  set  up  the  job  queues  for  the  altrouting  and  normaliza¬ 
tion  control  activities  require  the  use  of  fault  isolation  reports  and  fault 
file  removals  (see  Report  3,  Sections  2.6.1  and  2.6.6),  When  ATEC  reports 
a  fault  isolation,  the  trunks  or  circuits  involved  are  placed  in  a  restoral 
precedence  (RP)  ranked  queue  for  altrouting.  The  segments  defining  the 
failed  and  intact  segments  of  the  normal  route  are  defined.  The  altroute  job 
is  then  ready  for  the  altroute  search.  The  removal  of  all  fault  files  from  a 
circuit  or  trunk  keys  the  normalization  job  queue  to  set  the  circuit  or  trunk 
up  for  normal  route  restoration.  These  activities  are  direct  parameter 
analysis  functions  which  are  implemented  in  software  at  ACOC. 

2.3.3  ACOC  Displays 

All  data  in  the  ACOC  data  base  is  conveniently  available  for  personnel  using 
the  system.  Displays  of  network  connectivity  and  status  aid  in  new  route 
planning.  The  historical  data  provided  by  network  equipment  test  reports 
can  be  used  to  assess  the  field  performance  of  equipment  and  aid  in  planning 
for  new  or  additional  equipment  requisitions.  These  and  other  displays 
support  any  activity  which  ACOC  personnel  might  be  required  to  perform. 

A  summary  of  the  proposed  ACOC  display  hierarchy  is  given  in  Figure  2-7. 
Figures  2-8  through  2-12  show  examples  of  some  of  these  displays.  Examples 
of  the  displays  in  the  altroute  plans  class  are  shown  in  Section  4  of  this 
report.  This  section  will  describe  the  content  of  each  display.  In  addition, 
we  will  discuss  the  linking  which  should  exist  between  displays  to  aid  in  using 
them  to  their  fullest. 
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Displays  fall  into  two  catagories:  summary  and  detail.  Each  summary 
display  has  an  operator  entry  field  to  access  detail  displays  listed  in  the 
summary  (Figure  2-8).  In  addition,  the  detail  displays  have  entry  fields 
for  accessing  the  display's  summary  display  and  related  displays  in  the 
display  class  (see  Figures  2-9,  2-10  and  2-11).  In  this  way  the  operator 
has  a  simple  and  logical  display  access  method.  The  displays  of  all  classes 
also  have  an  annunciator  field  similar  in  function  and  operation  to  that 
proposed  for  ATEC  displays  (see  Figures  2-8  through  2-12).  The  field  has 
a  flashing  annunciator  character  for  each  class  to  indicate  an  addition  or 
change  in  any  display  in  the  class.  Entering  a  character  into  the  entry  field 
immediately  calls  the  summary  display.  The  new  entries  themselves  would 
have  a  "new  entry"  flashing  character  to  emphasize  their  presence  the  first 
time  the  summary  is  accessed  after  the  new  entry  is  made. 

The  display  classes  and  their  content  are  summarized  here  to  set  some 
minimum  design  guidelines: 

Connectivity  Path  Status: 

•  Connectivity  Path  Status  Summary:  A  graphic  display  of  the 
DCS  network  (Figure  2-8)  giving  status  warnings  via  flashing 
characters  on  a  link  or  station. 

•  Critical  Connectivity  Path  Disturbance  Summary:  Lists 
all  critical  transmission  media  in  the  network  which  are 
failed  in  order  of  importance  and  outage  time. 

•  Critical  Connectivity  Path  Disturbance  Detail:  The  details 

of  transmission  failures  such  as  failure  cause,  RPs  impacted, 
etc.  are  given  in  this  display  (see  Figure  2-9). 
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Reporting  Disturbance  Detail  Display 


•  Critical  Service  Impact  Summary:  Lists  the  high  priority 
circuits  or  trunks  impacted  by  current  failures  (see  Figure  2- 

•  Critical  Service  Impact  Detail:  Identifies  details  about  the 
circuits  or  trunks  of  high  priority  which  are  impacted  by 
current  failures.  Lists  items  such  as  user,  phone  number 
of  user,  critical  normalization  plan,  etc. 

•  Station  Disturbance  Summary:  Lists  all  disturbance  details 
associated  with  the  station  being  displayed. 

Reporting  Status: 

•  Reporting  Status  Summary:  Summarizes  all  ATEC  sectors 
and  DSCS  NCEs  which  have  missed  scheduled  report  times. 

•  Report  Index:  Allows  retrieving  any  transmission  system 
report  submitted  to  ACOC  for  review. 

•  Report  Detail:  Actual  ACOC  report  text. 

•  Report  Disturbance  Detail:  Lists  the  overdue  reports  on  a 
sector  or  NCE  control  area  basis  (see  Figure  2-12). 

Network  Resources  Status: 

•  Station  Resource  Summary:  List  of  trunks  terminating  at  a 
station  and  details  per  the  "station  file"  data  base  entry 
(Report  2,  Table  3-13). 

•  Link  Detail:  Source,  destination,  and  other  details  per  the 
"link  file"  data  base  entry  (Report  2,  Table  3-15). 


•  Trunk  Detail:  Source,  destination,  circuits  carried,  and 
other  details  per  the  "trunk  file"  data  base  entry  (Report  2, 
Table  3-16). 

•  Circuit  Detail:  The  source,  destination,  trunk  list  of  the 
route,  and  other  details  per  the  "circuit  file"  data  base 
entry  (Report  2,  Table  3-17). 

•  Fault  Detail:  Lists  a  transmission  failure,  service  affected, 
and  other  details  per  the  "fault  file"  data  base  entry  (Report  2, 
Table  3-18). 

•  Multiplex  Diagrams:  A  graphic  display  of  groups  forming  a 
link  between  two  stations. 

Altroute  Plan  Status: 

•  Altroute  Plan  Summary:  Display  of  an  altroute  patching 

plan  for  all  stations  involved  in  the  altroute  (see  Figure  4-15). 

•  Altroute  Plan  Station  Details:  A  subset  of  the  plan  summary 
dealing  with  a  specific  station’s  patching  (see  Figure  4-16). 

•  Normalization  Plan  Summary:  Display  of  a  normal  route 
normalization  patching  plan  for  all  stations  involved  (see 
Figure  4-21). 

•  Normalization  Plan  Station  Details:  A  subset  of  the  plan 
summary  dealing  only  with  a  specific  station’s  patching 
(see  Figure  4-22). 
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2.  4  CONTROL  IMPLEMENTATION 

2.4.1  Introduction 


One  transmission  system  control  which  has  been  assigned  to  ACOC  is  altroute 
generation  for  failed  route  conditions.  Section  4  of  this  report  discusses 
reasons  for  applying  this  control  at  ACOC.  The  main  arguments  in  favor  of 
altroute  control  at  ACOC,  rather  than  at  sectors,  were  ease  of  maintaining 
data  base  consistency  and  computer  availability.  This  section  summarizes 
the  altroute  control  algorithms  and  inter- site  communications  required  to 
implement  these  controls.  The  companion  control  of  route  normalization  is 
also  addressed.  The  detail  references  for  this  discussion  are  Section  2  of 
Report  3  (altroute  algorithms)  and  Section  4  of  this  report  (implementation). 

2.4.2  Altroute  Control 


2. 4. 2.1  Altroute  Searching  Algorithms- -The  main  transmission  control 
recommended  is  automated  altroute  generation.  An  automated  tool  for 
altroute  generation  will  assist  in  the  maintenance  of  effective  critical  restoral 
plans  and  the  timely  selection  of  new  alternate  routes  should  that  become 
necessary.  The  inputs  for  the  algorithms  are  the  fault  isolation  reports  of 
ATEC  and  the  status  messages  from  ATEC  and  DSCS/CS.  The  fault  isola¬ 
tion  and  status  reports  initiate  algorithm  execution  and  allow  the  ACOC  data 
base  to  stay  current  so  that  reliable  altroutes  are  constructed. 

The  actual  altrouting  algorithm  is  a  package  of  algorithms  which  support 
the  altroute  search  routines  (see  Figure  2-13).  ATEC  and  DSCS/CS  fault 
isolation  reports  enter  the  main  calling  routines  where  a  queue  is  maintained 
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for  the  search  routines  so  that  the  most  crucial  services  receive  priority 
attention.  The  definition  of  failed  and  intact  segments  from  which  the 
altroute  must  begin  are  also  determined  here  in  order  to  group  jobs  requiring 
similar  altroutes.  The  goal  station  definition  routines  perform  this  segment 
definition  as  a  service  to  the  main  calling  routines.  The  next  step  is  to 
begin  work  on  the  job  queues  that  have  been  created.  Trunks  are  altrouted 
first,  then  circuits,  and  finally  sub-vf  circuits.  The  order  of  this  work 
schedule  ensures  that  the  largest  number  of  users  are  handled  first.  The 
main  calling  routines  call  their  corresponding  altroute  search  routines  to 
actually  synthesize  the  altroutes.  Those  routines,  in  turn,  make  use  of 
the  cost  calculating  routine  and  heuristic  cost  estimation  routine  in  order 
to  select  the  most  desirable  routing.  Failure  to  altroute  at  a  given  level 
(trunk,  circuit)  will  result  in  decomposition  of  the  service  into  its  lower- 
level  multiplex  services  and  submission  of  those  services  for  altrouting. 

A  key  concept  in  the  search  algorithm  is  the  node  labelling  process.  A 
variation  of  this  process  is  the  basis  of  this  or  any  other  network  search 
algorithm.  Figure  2-14  shows  the  node  labelling  routine  in  flow  chart  form; 
however,  the  easiest  way  to  understand  the  routine  is  through  an  example. 
Referring  to  Figure  2-15,  we  will  use  the  algorithm  of  Figure  2-14  to  find 
a  minimum  cost  path  from  node  S  to  node  G  in  this  simple  network.  The 
numbers  alongside  each  link  represent  a  "cost"  of  some  sort  which  defines 
the  desirability  of  using  the  link  on  the  path  to  be  found.  The  actual  altroute 
search  can  assign  costs  for  the  DCS  links  to  reflect  desirability.  The  search 
begins  by  selecting  the  lowest  cost  node  listed  as  OPEN.  Nodes  in  list 
OPEN  have  been  accessed  already  and  added  to  a  path,  but  they  have  not 
been  examined  for  path  expansion  yet.  The  only  node  at  this  time  is  S. 

Nodes  A,  B,  and  D  are  found  to  be  accessible  from  S.  Each  has  a  label 
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ENTER  THE  STARTING 


Figure  2-14.  Node  Labelling  Routine 


assigned  to  it  indicating  the  node  used  to  access  it  (that  is,  its  "parent 
station")  and  the  cost  of  the  path  from  S  to  the  node.  Once  ail  accessible 
nodes  are  labelled,  node  S  is  labelled  as  CLOSED.  Nodes  in  list  CLOSED 
are  nodes  on  a  path  and  have  been  examined  for  path  expansion  already. 

Examining  all  nodes  labelled  OPEN,  we  see  that  the  next  node  for  path 
expansion  (due  to  its  low  "cost")  is  node  A  (see  Figure  2-16). 

The  nodes  accessible  from  A  are  S,  C,  and  B.  Labels  are  made  for  all 
nodes  from  A.  Those  labels  which  have  a  higher  cost  than  that  from  the 
current  label  are  not  kept.  Labels  which  supply  a  previously  labelled  node 
with  a  lower  cost  are  kept  and  the  previous  labels  discarded.  The  "parent 
station"  string  defines  the  path  to  any  node.  The  label  on  C  indicates  the 
path  to  it  came  from  A,  and  A's  label  indicates  that  S  preceded  it  on  the 
path  through  it. 

The  algorithm  proceeds  similarly  from  nodes  B  (Figure  2-17)  and  D 
(Figure  2-18).  Because  G  was  labelled  from  D  does  not  mean  the  search  is 
complete.  The  path  from  D  has  a  cost  of  5,  while  the  lowest  cost  is  4  over 
a  path  from  C.  The  search  terminates  when  the  goal  node  (G)  is  selected  as 
the  lowest  cost  node  in  OPEN.  Using  this  type  of  termination  guarantees 
that  the  lowest  cost  path  is  found.  Figure  2-19  shows  C  labelling  G  with 
lower  cost  and  thus  setting  up  the  discovery  of  G  as  the  lowest  cost  OPEN 
node  to  expand.  The  path  search  ends  and  the  path  S  to  B  to  C  to  G  with 
cost  4  is  found  as  optimum. 

Relating  this  to  the  DCS,  the  nodes  are  stations  at  which  circuits  and  trunks 
can  be  patched.  The  links  refer  to  trunks  (for  circuit  altrouting)  or  links 
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(for  trunk  altrouting).  The  search  for  stations  accessible  from  an  OPEN 
station  is  a  search  for  spare  or  preemptable  circuits  or  trunks  which  the 
altrouted  circuits  or  trunks  can  use  to  that  station. 

The  link  costs  for  the  altroute  search  algorithm  reflect  the  desirability  of 
the  route  and  the  preemption  penalty  paid  for  its  use.  Costs  which  are 
recommended  for  the  search  are: 

•  Mileage  of  the  altroute  over  DCS  transmission  facilities 

•  Sum  of  the  RPs  of  the  circuits  preempted  in  order  to  use 
the  altroute 

•  Number  of  patching  stations  involved  in  creating  the  altroute 

•  Type  and  reliability  of  the  links  used  in  the  altroute 

The  first  and  third  items  in  the  list  are  already  route  desirability  considera¬ 
tions  for  DCS  route  planning.  The  other  two  are  operational  performance 
criteria  used  informally  by  tech  controllers  in  selecting  altroutes. 

The  variation  of  the  node  labelling  routine  that  makes  the  altroute  search 
effective  and  timely  is  the  addition  of  heuristic  cost  estimates  to  the 
expansion  of  a  path  node.  The  labelling  routine  described  in  the  example 
labelled  nearly  all  nodes  before  terminating.  The  altroute  search  must 
label  fewer  nodes  to  be  effective.  The  technique  for  accomplishing  this 
is  to  estimate  the  cost  of  the  altroute  from  the  current  search  station  to 
the  goal  station  even  though  the  path  to  the  goal  is  not  yet  determined.  This 
estimate  can  be  made  with  heuristic  knowledge  of  the  problem,  as  Report  2 
(Section  2.6.4)  points  out.  The  effect  of  adding  this  estimated  cost  to  the 
actual  cost  is  to  avoid  penalizing  a  path  expansion  from  further  consideration 


just  because  it  is  longer  than  other  paths.  Since  the  sum  of  known  and 
estimated  costs  at  each  OPEN  node  is  the  full  path  cost,  short  and  long 
partial  paths  are  weighted  equally.  Thus,  the  optimum  path  is  found  quickly 
without  slowing  the  search  with  a  large  number  of  possibilities  which  will 
ultimately  prove  nonoptimum. 

2. 4. 2. 2  Altroute  Implementation- -The  definition  of  altrouting  control  is 
not  complete  unless  the  inter- site  communication  for  altroute  implementation 
is  defined.  The  previous  section  defined  the  algorithm  support  that  altrouting 
control  has  at  its  disposal.  The  current  section  addresses  how  to  make  use 
of  the  algorithm  results. 

The  summary  of  the  activities  that  will  take  place  between  DCS  operations 
sites  during  altrouting  are  given  in  Figure  4-5  of  this  report.  Section  4.3.1 
which  accompanies  that  figure  details  the  activities.  The  control  flow  begins 
with  transmission  system  fault  isolation  reports.  If  the  estimated  time  of 
repair  (ETR)  of  the  equipment  permits,  ACOC  algorithms  find  an  altroute. 
The  altroute  patching  plan  appears  at  the  ACOC  display  simultaneous  to  the 
fault  isolation  report.  This  provides  the  controller  with  a  solution  to  the 
problem  causing  the  alert  which  may  be  immediately  approved  and  imple¬ 
mented. 

Once  ACOC  approval  of  the  plan  is  obtained,  patching  messages  are  sent 
to  involved  stations  via  the  ATEC  message  channels.  The  stations  review 
the  plan  to  determine  if  it  coincides  with  the  current  status  of  equipment 
being  used  at  their  station.  This  step  allows  status  updates  that  were 
erroneous  to  be  corrected  and  allows  late  updates  to  be  included  in  the  plan. 
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Once  all  stations  concur  with  the  plan,  ACOC  sends  the  final  instruction  to 
all  of  them  to  implement.  The  data  base  links  to  the  new  altrouted  are  then 
made.  Rejection  of  a  plan  at  a  station  is  accompanied  by  an  exception  report 
to  enable  ACOC  control  to  modify  the  data  base  in  order  for  a  subsequent 
altroute  search  to  succeed.  The  details  of  the  displays  for  this  are  given  in 
Figures  4-9  through  4-17  of  this  report. 

2.4.3  Route  Normalization 


2.4.3. 1  Normalization  Algorithms- -Once  equipment  repair  has  occurred, 
altrouted  circuits  or  trunks  must  be  routed  back  to  their  normal  routes  in 
order  to  remove  preemptions  that  may  have  been  made.  The  normalization 
routine  described  in  Report  3  (Section  2.6.6)  accomplishes  this  task. 

The  input  to  activate  a  route  normalization  is  the  repair  of  equipment  on  the 
normal  route.  The  presence  of  this  condition  is  sensed  by  the  removal  of 
the  last  fault  file  attached  to  a  circuit  or  trunk  in  the  data  base  (see  Figure 
2-6).  An  initial  check  is  made  to  determine  if  the  normal  route  contains  any 
preemptions.  Preemptions  on  the  normal  route  cannot  be  removed  because 
the  preempting  circuit  or  trunk  must  have  had  a  higher  RP  to  preempt  in  the 
first  place.  If  this  is  the  case,  the  normalization  job  is  queued  with  other 
jobs  until  the  preemptions  are  removed  from  its  normal  route.  If  the 
normalization  can  be  made,  the  patching  messages  are  assembled  for 
normalization.  The  normalization  may  have  removed  preemptions  from 
circuits  or  trunks  waiting  in  the  normalization  queue.  The  job  queue  is 
checked  for  this  condition,  and  normalization  is  carried  out  for  circuits  or 
trunks  which  are  now  free  of  all  preemptions. 
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2. 4.  3.2  Implementation  of  Normalization- -To  complete  the  normalization 
control  implementation,  the  inter-site  communications  to  carry  out  the 
patching  are  defined.  Figure  4-6  in  this  report  summarizes  the  activity  in 
flow  chart  form.  Section  4.3. 1  accompanying  the  figure  details  the  procedure 
of  the  flow  chart.  The  activity  follows  the  altroute  implementation  almost 
exactly.  The  messages  sent  for  patching  are  similar  in  order  to  minimize 
confusion.  The  station  approval  requirement  of  patching  again  verifies  the 
timeliness  of  the  ACOC  data  base. 

2.  5  SUMMARY  OF  TRANSMISSION  CONTROL 

This  section  has  briefly  reviewed  the  results  of  the  transmission  system 
control  design  of  Reports  2  and  3  of  this  study.  The  four  main  areas  of 
design  (parameter  collections,  communications,  analysis,  and  control 
implementation)  have  been  addressed  in  order  to  demonstrate  the  feasibility 
of  the  design. 

The  results  of  this  control  design  are: 

•  A  data  base  design  to  support  network  connectivity 

•  Displays  of  data  base  files  arranged  to  support  key  ACOC 
requests  for  information 

•  An  altrouting  package  to  aid  in  restoring  service  around 
failed  transmission  segments  in  order  to  improve  service 
availability 
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AUTOVON  CONTROL 

3. 1  PARAMETER  COLLECTION 

The  portion  of  this  study  in  reference  2  was  based  on  AUTOSEVOCOM  II 
using  the  AN/TTC-39  and  SB-3865  switches.  The  details  of  the  parameter 
selection  and  collection  methodologies  contained  therein  are  not  applicable 
to  the  490L  network.  However,  the  general  approach  to  parameter  selection 
is  independent  of  the  details  of  the  switching  hardware  employed.  Since 
AUTOSEVOCOM  II  was  cancelled,  this  analysis  has  been  revised  to  reflect 
the  requirements  of  490L  AUTOVON. 

Circuit  switched  network  parameters  basically  fall  into  two  classes  as 
follows: 

•  Traffic  parameters 

•  Equipment  status  parameters 

These  types  of  parameters  are  not  independent  of  each  other  as  changes  in 
equipment  status  modify  observed  traffic  parameters.  There  are  parameters 
which  do  not  neatly  fit  in  either  class  such  as  trunk  timeouts.  However, 
for  the  purposes  of  exposition,  it  is  useful  to  make  this  breakdown. 

Traffic  parameters  measure  the  demand  for  service  in  the  network  and  are 
typically  counts  of  events  or  measures  of  average  utilization  of  network 
equipment.  Although  the  status  of  network  equipment  could  be  deduced  from 


them,  we  recommend  against  this  use  of  traffic  parameters  for  the  following 
reasons: 

•  All  forms  of  equipment  status  changes  can  either  be  alarmed  on 
occurrence  or  can  be  monitored  by  scanning  at  frequent  intervals. 

•  Traffic  parameters,  being  driven  by  a  stochastic  process,  require 
extensive  smoothing  before  being  applied  to  an  alarm  threshold. 

•  Network  equipment  status  changes  have  complex,  nonlinear  inter¬ 
actions  with  traffic  parameters  throughout  the  network. 

•  It  would  be  very  difficult  to  separate  traffic  parameter  changes 
due  to  network  status  changes  from  those  due  to  traffic  level 
changes. 

Therefore,  traffic  parameters  are  recommended  for  determining  the  network 
traffic  level.  Since  the  history  of  the  actual  traffic  level  is  completely 
independent  of  the  future  traffic  level,  there  is  also  no  way  that  traffic 
parameters  could  be  used  to  predict  or  trend  traffic  levels.  Traffic  level 
predictions  can  only  be  made  based  on  daily,  weekly,  and  seasonal  business 
cycles  and  other  external  information  such  as  defense  condition  (DEFCON). 

3.1.1  Traffic  Parameters 

The  traffic  parameter  selection  matrix  for  the  AUTOVON  switch  is  shown 
in  Table  3-1.  They  are  based  on  the  analysis  contained  in  the  following 
paragraphs. 
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TABLE  3-1.  TRAFFIC  PARAMETER  SELECTION  MATRIX 


Parameters 

Sampling 

Interval 

(Min) 

Real- 

Time 

Use 

Long-Term 

Engineering 

Use 

Node  Parameters 

Local  calls  offered 

60 

X 

Call  originations 

60 

X 

Calls  terminated 

60 

X 

Tandem  calls 

60 

X 

Calls  blocked,  by  precedence 

10 

X 

Calls  with  dial  tone,  delay 

1  second 

10 

X 

Calls  complete,  by  node 

60 

X 

Trunk  Parameters 

Calls  offered,  total 

10 

X 

X 

Calls  offered,  by  precedence 

10 

X 

Calls  blocked,  no  idle  trunk 

10 

X 

X 

Calls  blocked,  no  common 
equipment 

10 

X 

Calls  incoming 

10 

Calls  preempted,  by  precedence 

10 

X 

Preempts  blocked,  by 
precedence 

10 

X 

Average  number  of  trunks  busy 

10 

X 

Time  congestion 

5 

X 

Trunk  timeout 

On 

Occurrence 

X 

/ 


There  are  three  types  of  traffic  parameters  as  follows: 

•  Node  parameters 

•  Trunk  group  parameters 

•  Source-destination  pair  parameters 

Node  parameters  give  information  about  the  traffic  at  the  switch  making 
the  report.  Typical  node  parameters  are  the  following: 

•  Local  calls  offered 

•  Call  originations  offered 

•  Call  terminated 

•  Tandem  calls 

•  Calls  blocked,  reported  by  precedence 

•  Calls  with  dial  tone  delay  greater  than  one  second 

Node  parameters  do  not  provide  enough  detail  for  real-time  system  level 
control  since  they  either  report  on  strictly  local  problems  or  are  too  sum¬ 
marized  to  provide  a  clear  picture.  Local  calls  offered  does  not  provide 
any  information  about  network  operations.  If  too  many  calls  have  delayed 
dial  tone,  the  local  switch  controller  should  apply  traffic  load  control  to 
reduce  the  demand.  Both  parameters  relate  to  strictly  local  phenomena. 
The  remaining  parameters  summarize  the  traffic  at  the  switch  and  could 
indicate  an  overall  switch  overload.  They  provide  no  detail  about  the 
characteristics  of  the  overload  which  is  needed  to  isolate  the  stress.  This 
detail  is  provided  by  the  trunk  group  parameters. 
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The  direct  indicator  of  processing  load  is  another  type  of  node  parameter. 

On  a  stored  program  contrplled  switch,  the  percentage  processor  utilization 
can  be  directly  measured  and  is  an  excellent  indicator.  With  common  chan¬ 
nel  signalling,  queue  sizes  can  be  directly  measured  and  used  as  a  switch 
congestion  indicator.  For  the  490L  switch,  the  parameters  are  the  following: 

•  •  Multiple  frequency  (MF)  tranceivers  busy 

•  Dual  tone  multiple  frequency  (DTMF)  receivers  busy 

•  Register  sender  junctors  (RSJs)  busy 

If  either  the  MFTs  or  the  RSJs  are  all  busy,  the  switch  starts  queuing  tan¬ 
dem  calls  for  call  processing.  If  DTMF  receivers  are  busy,  local  dial  tone 
will  be  delayed.  Queuing  of  tandem  calls  causes  increased  use  of  interswitch 
trunks  for  signalling  purposes.  If  this  becomes  critical,  trunk  timeouts  will 
occur;  and  the  network  may  go  into  a  thrashing  state  (defined  as  a  condition 
in  which  increased  offered  traffic  rest  Its  in  decreased  carried  traffic).  The 
MFT  and  RSJ  busy  parameters  must  therefore  be  processed  to  identify 
switch  overload. 

The  parameters  which  could  be  collected  for  each  trunk  group  include  the 
following  counts  of  events: 

•  Calls  offered,  total  and  itemized  by  precedence 

•  Calls  blocked  due  tj  lack  of  idle  trunks 

•  Calls  incoming  on  the  trunk  group 

•  Calls  preempted,  by  precedence 

•  Preempts  refused,  by  precedence 
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Trunk  utilization 


•  Time  congestion 

•  Trunk  timeout 

Calls  offered  (attempts)  is  the  basic  traffic  parameter.  It  is  a  direct  count 
of  every  attempt  to  use  the  trunk  group.  By  assuming  an  average  time 
which  any  call  would  use  the  trunk,  calls  blocked  and  preempted  can  be 
estimated  via  the  Erlang  formulas.  Call  attempts  are  not  measured  by 
AUTOVON  centralized  alarm  system  (AC AS)  sensors.  They  are  measured 
by  traffic  data  collection  system  (TDCS),  but  this  equipment  is  questionable 
as  discussed  in  Section  4.  2.  2. 1.  A  parameter  which  is  statistically  equiva¬ 
lent  for  Poisson  traffic,  time  congestion,  is  sensed  by  ACAS.  Thus,  for 
basic  real-time  control  attempts  are  not  required.  For  long  term  engineering 
or  more  precise  distribution  free  control,  attempts  should  be  measured. 

Calls  blocked  due  to  the  lack  of  idle  trunks  (overflows)  is  the  next  most 
direct  traffic  parameter.  Using  this  count  along  with  the  number  of  calls 
offered  provides  an  estimate  of  trunk  group  performance  which  does  not 
depend  on  assumptions  about  the  hold  times  or  the  statistical  distribution  of 
attempts.  There  are  disadvantages  to  using  this  parameter,  as  follows: 

•  Poisson  statistics,  using  a  historically  derived  hold  time,  predict 
network  performance  fairly  well.  This  is  especially  true  in  a 
network  like  AUTOVON  where  trunk  groups  are  not  used  as 
strictly  high  usage  or  final  trunk  groups  but  have  some  of  each 
kind  of  traffic. 
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•  Overflows  are  noisier  than  attempts,  that  is,  they  come  less 
frequently  and  tend  to  come  in  bursts  so  a  performance 
estimate  based  on  overflows  would  need  more  smoothing  than 
one  based  on  attempts. 

It  would  be  useful  to  filter  and  threshold  the  ratio  of  overflows  to  attempts 
as  a  backup  to  thresholding  just  attempts  in  case  the  average  hold  time 
changes  drastically,  due  to  military  conditions  for  example.  It  must  be 
recognized  that  the  observed  call  blocking  ratio  will  be  slower  to  respond 
when  appropriately  filtered  than  the  attempts  parameter.  As  with  attempts, 
overflows  are  not  measured  by  A  CAS. 

Calls  incoming  on  the  trunk  group  is  a  redundant  parameter  which  is  not 
useful  if  the  control  point  has  visibility  of  both  ends  of  the  trunk.  It  is  just 
attempts  minus  overflows  from  the  other  end.  This  parameter  would  be 
useful  if  some  sort  of  distributed  control  scheme  was  contemplated,  but  it 
has  no  place  in  the  DCS  hierarchical  control  structure. 

Calls  preempted  and  preempts  refused  are  indicators  of  the  basic  traffic 
level,  but  they  are  very  noisy  parameters  and  hence  not  useful  for  real¬ 
time  system  control.  They  are  noisy  in  the  sense  that  a  preempt  attempt  is 
generated  only  if  all  alternate  routes  overflow  on  an  idle  search.  Each 
time  an  overflow  process  occurs,  it  has  a  larger  ratio  of  variance  to  mean 
than  the  arrival  process  which  generated  it.  Since  a  preempt  is  an  overflow 
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of  the  final  trunk  group,  preempts  have  a  very  large  variance  to  mean 
ratio.  In  addition  to  being  noisy,  preemption  counts  still  contain  only 
basic  traffic  intensity  data  the  same  as  idle  attempts.  Therefore,  these 
parameters  are  not  useful  for  real-time  system  control.  They  are  useful 
for  long-term  engineering  studies  to  determine  if  the  precedence  system  is 
operating  properly.  In  some  network  designs,  preemption  algorithms 
transfer  precedence  ratings  between  calls  in  an  erroneous  manner.  This 
could  be  detected  by  long-term  analysis  of  preemption  count  data. 

Trunk  group  utilization  is  obtained  by  scanning  the  trunk  group  every  few 
seconds  and  counting  the  number  of  busy  trunks.  The  scan  data  is  then 
averaged  over  the  measurement  interval  of  several  minutes.  For  example, 
reasonable  measurement  rates  would  be  every  30  seconds  averaged  over 
15-30  minutes.  Trunk  utilization  provides  another  good  estimator  of  traffic 
intensity  and  is  a  valid  alternative  to  measuring  attempts.  Combined  with 
measurements  of  attempts  and  overflows,  it  removes  distribution  dependent 
assumptions  in  the  measurement  and  can  provide  good  information  on  what 
the  actual  arrival  distribution  is.  It  is  therefore  a  very  useful  parameter 
for  long-term  engineering  of  the  network.  Time  congestion  is  another 
equivalent  measure  of  traffic  intensity.  It  is  measured  by  computing  the 
portion  of  a  measurement  interval  during  which  all  trunks  are  in  use.  Time 
congestion  is  the  traffic  parameter  actually  measured  by  the  ACAS  system. 
Since  time  congestion  is  statistically  equivalent  to  attempts  or  utilization, 
it  is  a  sufficient  measure  of  traffic  intensity  and  is  the  only  parameter 
required  for  real-time  control. 
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Trunk  timeouts  are  counts  of  calls  which  never  receive  a  start  signal  from 
the  distant  end  switch.  This  parameter  is  useful  in  two  ways.  If  the 
number  of  timeouts  is  about  equal  to  the  number  of  attempts,  the  trunk  has 
apparently  failed.  If  the  number  of  timeouts  is  much  smaller  than  the 
number  of  attempts,  but  greater  than  zero,  it  is  an  indicator  of  critical 
congestion  at  the  distant  end  switch.  Upon  confirmation  of  critical  con¬ 
gestion,  control  actions  would  be  taken  to  relieve  the  switch.  This 
parameter  exists  only  for  trunks  using  in-band  signalling. 

Source-destination  pair  parameters  relate  to  user-user  traffic  handling. 

The  same  basic  kinds  of  parameters  as  for  trunks  exist,  calls  attempted, 
completed,  preempted,  etc.  These  parameters  are  all  very  interesting  for 
long-term  engineering.  In  the  Bell  system,  these  parameters  are  used  to 
modify  routing  rules.  In  AUTOVON,  the  traffic  patterns  are  too  simple  and 
the  network  too  small  to  require  the  use  of  these  parameters  for  real-time 
control. 

Smoothing  of  Traffic  Parameters — Traffic  parameters  are  random  variables 
and  therefore  typically  have  to  be  smoothed  to  be  useful.  The  smoothing 
required  is  very  much  a  function  of  the  exact  use  of  the  parameter  and  some 
arbitrary  decision  criterion.  In  the  case  of  system  control,  the  expected 
use  of  the  smoothed  parameter  is  to  make  a  decision  whether  the  observed 
parameter  came  from  a  stressed  traffic  situation  or  from  a  normal  unstressed 
traffic  situation.  This  decision  is  made  by  placing  a  threshold  on  the  smoothed 
parameter  value. 


/ 


Reference  2  contains  a  discussion  of  smoothing  criteria.  In  general, 
smoothing  time  requirements  have  the  following  characteristics: 

•  Required  smoothing  decreases  with  larger  trunk  groups. 

•  Required  smoothing  decreases  with  heavier  traffic. 

•  Required  smoothing  increases  with  the  peakedness  of  the  traffic. 

•  Smoothing  time  is  more  sensitive  to  nominal  GOS  than  it  is 
to  the  number  of  trunks  in  the  group  or  the  peakedness  of  the 
traffic. 

For  detecting  overloads  on  trunk  groups  typical  of  AUTOVON,  smoothing 
times  on  the  order  of  30  minutes  are  required. 

Relation  of  Traffic  Parameters  to  Network  Status  Parameters- -The  use 
postulated  for  traffic  parameters  is  to  detect  changes  in  network  traffic 
loads.  For  any  given  trunk  group,  the  change  can  be  caused  either  by  a 
change  in  the  basic  demand  for  service  or  by  a  change  in  the  network  status. 
If  the  traffic  level  change  is  due  to  a  change  in  network  status,  it  would  have 
been  predictable  based  on  network  status  parameters.  No  further  informa¬ 
tion  is  obtained  by  observing  that  the  traffic  levels  respond  to  the  new  net¬ 
work  status. 

If  the  traffic  alarm  thresholds  are  not  changed  and  the  demand  for  service 
as  well  as  the  network  status  changes,  there  is  no  way  to  separate  an  alarm 
due  to  network  status  from  an  alarm  due  to  traffic.  Therefore,  whenever  the 
network  status  changes,  the  alarm  thresholds  for  traffic  monitoring  should 
be  modified  so  that  they  still  relate  to  changes  in  the  demand  for  service; 
that  is,  they  discount  changes  due  to  a  changed  network. 
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This  modification  of  the  threshold  values  can  be  accomplished  by  using  a 
steady  state  model  of  the  network  to  determine  new  nominal  traffic  values. 
Threshold  offsets  of  some  percentage  can  be  applied  to  these  traffic  values. 
These  expected  traffic  values  and  the  resulting  performance  figures  can  be 
presented  to  the  controller  as  further  detail  into  what  the  status  change  means 
relative  to  network  performance. 

3.1.2  Equipment  Status  Parameters 

Equipment  status  information  must  be  accurate,  timely,  unambiguous  and 
comprehensive  in  order  to  effectively  control  the  network.  Equipment  failures 
can  cause  distortion  of  the  traffic  flow  misleading  the  controllers  as  to  the 
cause  of  the  network  stress.  Further,  if  equipment  failures  are  known,  the 
remaining  network  can  be  reconfigured  to  maximize  its  utilization.  For 
these  reasons,  DCAC  310-55-1  (Reference  5)  specifies  that  any  significant 
AUTOVON  equipment  failure  should  be  immediately  reported  to  ACOC. 

Table  3-2  lists  the  equipment  parameters  required  for  AUTOVON.  For 
each  parameter  the  on-line  unit,  number  of  units  failed,  and  number  of  units 
operational  should  be  sent  to  ACOC  upon  the  occurrance  of  a  change  of  state. 
This  differs  from  the  current  A  CAS  procedure  which  purports  to  show  the 
equipment  out  of  service.  A  CAS  provides  only  a  one  or  more  failed  indica¬ 
tion  of  multiple  frequency  transceiver  (MFT),  RSJ  and  DTMF  equipments. 

In  the  case  of  the  marker,  it  indicates  failure  if  the  marker  fails  to  complete 
its  cycle  successfully,  resulting  in  a  marker  switchover.  Since  one  marker 
is  always  on  line,  the  ACAS  display  always  indicates  one  marker  operational. 
The  parameter  sensor  should  indicate  marker  failure  when  initial  switchover 
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TABLE  3-2.  490L  SWITCH  STATUS  ITEMS 
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occurs,  but  it  should  continue  to  indicate  failure  if  the  marker  comes  back 
on  line  until  a  cycle  is  successfully  completed. 

In  addition  to  basic  event  parameters,  ACOC  needs  to  be  informed  if  any 
local  controls  are  taken  which  impact  network  operations.  These  informal 
parameters  are  the  following: 

•  Line  load  control  applications 

•  Routing  table  change 

•  Translation  table  change 

•  Zone  restriction  change 

•  Trunk  directionalization 

•  Manual  make  busy  of  common  equipment  or  trunks 


3.2  PARAMETER  COMMUNICATION 

As  discussed  in  Section  4,  the  collection  point  for  all  AUTOVON  parameters 
at  the  switch  site  is  the  RAMM.  These  parameters  all  go  to  the  ACOC 
AUTOVON  control  data  base.  In  reference  2  it  was  shown  that  the  communi¬ 
cation  needline  for  periodic  reporting  from  the  TTC-39  switch,  as  used  for 
a  replacement  AUTOVON  switch,  is  less  than  10  BPS. 

Another  estimate  can  be  obtained  by  examining  the  TDCS  data  flow.  For 
a  switch  with  10  trunks  and  10  destinations,  TDCS  counts  482  items.  The 
item  with  the  largest  count  is  the  total  attempts  at  the  switch.  The  busiest 
switch  has  a  traffic  load  of  under  50E,  so  certainly  less  than  50  attempts/ 
minute  are  made.  Thus,  the  maximum  value  of  an  hourly  count  is  300,  and 
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a  3-digit  count  field  is  sufficient.  At  10  bits /character,  the  total  data  rate 
is  4  BPS.  Allowing  100%  overhead  for  message  formatting  and  error  checking, 
a  transmission  rate  of  8  BPS  is  obtained.  Therefore,  the  10  BPS  needline  is 
a  reasonable  estimate  for  periodic  traffic  reporting  on  switches  the  size  of 
European  AUTOVON. 

Reporting  of  equipment  status  does  not  need  to  be  done  on  a  periodic  basis, 
but  rather  only  when  a  change  in  status  occurs.  With  this  type  of  reporting 
system,  the  communications  path  must  be  sized  according  to  the  worst  case 
delay  which  is  tolerable.  In  reference  2,  a  120  BPS  requirement  was 
determined  for  the  TTC-39  switch.  This  requirement  is  also  reasonable 
for  the  490L/RAMM  system. 

There  are  basically  four  logical  candidates  for  telemetry  of  AUTOVON  data: 

•  A  dialup  system  currently  used  to  TDCS 

•  ACAS  telemetry  circuits 

•  AT  EC  via  a  CIS  port 

•  AT  EC  via  a  NCS  system  control  (SYSCON)  port 

The  dialup  system  used  by  TDCS  is  a  1200  baud  system  and  therefore  has 
sufficient  capacity.  However,  it  uses  the  reported  on  switch  as  a  part  of 
its  reporting  path  and  is  therefore  unavailable  when  needed  most.  ACAS 
has  dedicated  75  baud  telemetry  circuits.  These  circuits  would  have  to  be 
upgraded  to  handle  the  120  BPS  requirement.  They  also  are  half  duplex 
reporting  to,  not  accepting  commands  from,  ACOC.  It  is  further  an 
inefficient  use  of  resources  to  dedicate  120  BPS  circuits  all  across  Europe 
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to  handle  a  10  BPS  average  requirement.  Thus  ATEC,  with  its  message 
switching  telemetry  structure,  is  a  highly  attractive  candidate  for  telemetering 
AUTOVON  data. 

ATEC  could  either  be  entered  on  a  150  baud  CIS  port,  looking  just  like 
another  MAS  element,  or  it  could  enter  the  node  directly  into  one  of  the 
specified  spare  2400  baud  circuits.  Since  AUTOVON  switches  are  located 
at  the  larger  DCS  stations,  it  is  possible  that  the  CIS  ports  are  fully  occupied. 
This  is  especially  true  if  all  the  other  CIS  interfaces  recommended  here  are 
implemented.  There  is  a  NCS  colocated  with  each  AUTOVON  switch  with  an 
unused  2400  baud  port,  and  the  HAMM  can  control  a  2400  baud  interface  as 
easily  as  a  50  baud  interface.  For  these  reasons,  it  is  recommended  that 
AUTOVON  switches  report  via  the  NCS  2400  baud  port.  NCS  and  SCS  still 
have  no  AUTOVON  function  except  to  transfer  messages  to  and  from  ACOC. 

3.3  PARAMETER  PROCESSING 

The  parameters  are  used  at  the  ACOC  for  the  following  functions: 

•  Provide  the  controller  with  accurate  real-time  status  of 
the  network 

•  Alert  the  controller  of  status  changes  requiring  attention 

•  Make  automatic  decisions  regarding  changes  in  routing 
procedures 

In  support  of  the  first  function,  parameter  reports  are  sorted  into  an 
AUTOVON  data  base.  This  data  base  contains  all  the  information  about  the 
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network’s  configuration  and  status  necessary  to  perforin  real-time  theatre 
level  AUTOVON  control  functions.  The  data  is  contained  in  the  following 
seven  file  types: 

•  Network  configuration  file 

•  Switch  equipment  status  and  history  file 

•  Switch  configuration  file 

•  Switch  traffic  file 

•  Trunk  group  status  file 

•  Trunk  group  traffic  file 

•  Critical  user  access  status  file 

The  interrelationship  of  these  files  is  shown  in  Figure  3-1.  The  content  of 
the  files  is  shown  in  Table  3-3  through  3-9.  For  a  network  the  size  of 
European  AUTOVON,  the  total  size  of  this  data  base  is  about  32,000  bytes. 

In  support  of  the  first  function,  a  set  of  displays  has  also  been  defined. 

These  displays  and  the  overall  display  concept  is  patterned  after  the 
AUTODIN  II  concept.  Controllers  may  cross-train  and  work  both  networks. 
By  using  a  similar  display  concept,  this  process  is  expedited.  Also,  the 
AUTODIN  II  display  concept  is  a  modern,  well  thought  out  system  of  displays. 
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AUTOVON  Data  Base 


TABLE  3-3.  NETWORK  CONFIGURATION  FILE 


Item 

Comments 

Size 

(Bytes) 

Switch  names 

Provides  correspondence  between  DCS 
station  name  and  network  logical  switch 
number.  Three  (3)  ASCII  characters 
per  switch. 

27 

Connectivity  table 

Provides  forward  pointer  from  network 
connectivity  to  logical  trunk  group 
names.  Two  (2)  BCD  digits  for  each  end 
of  each  trunk  group,  indicating  termin¬ 
ating  switch. 

50 

TOTAL  77 

- - 1 _ 

Number  of  such  records- -1 
Total  bytes- -77 
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TABLE  3-4.  SWITCH  EQUIPMENT  STATUS  AND  HISTORY  FILE 

Status  and  history  subrecord  for  each  reportable  piece  of 
equipment  listed  in  table,  containing  the  following: 


Item 

Comments 

Size 

(Bytes) 

Number  operating 

Provides  indication  of  operating  resource. 

1 

Number  standby 

Provides  indication  of  reserve  resource. 

1 

Number  failed 

Provides  indication  of  currently  inoperable 
resource. 

1 

Failure  rate 

Total  number  of  failures /total  operating 
time  required  by  310-130-2. 

4 

Average  restoral 
time 

Used  by  controller  to  determine  whether  or 
not  a  response  to  a  stress  is  appropriate. 

1 

Average  repair 
time 

Same  as  restoral. 

1 

Number  of 
accumulated 
failures:  daily, 
monthly,  yearly 

Used  by  controller  to  be  aware  of  abnormal 
failure  problems.  Provides  controller  with 
insight  as  to  what  may  be  expected  to  fail, 
so  that  he  does  not  place  excessive  demands 
on  weak  equipment. 

3 

Failure  time  integral 

Total  time  a  piece  of  equipment  has  been 
in  a  failed  state;  provides  measure  of 
equipment  availability. 

6 

TOTAL 

18 

Number  of  records  per  switch--15 


Total  records--150 
Total  bytes--2700 
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TABLE  3-5.  SWITCH  CONFIGURATION  FILE 


Item 

Comments 

Bytes 

Routing  table 

Expanded  to  support  adaptive  routing. 
Includes  for  each  destination 
switch  the  switch  number  (2  binary 
coded  decimal,  digits),  each  seg¬ 
ment  of  a  route  to  that  destination 
for  each  trunk  group  exiting  this  switch, 
and  its  status  (50  bytes). 

510 

Trunk  groups 

Number  of  each  trunk  group  terminating 

20 

in  operation 

on  this  switch. 

Code  translation 

Contains  station  and  line  code  trans- 

100 

tables 

lations  used  for  inter- networking 
and  ring-around-the-rosey  prevention. 

TOTAL 

630 

Number  of  such  records- -10 
Total  bytes--6300 
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TABLE  3-6.  SWITCH  TRAFFIC  FILE 


Item 

Comments 

Automatic  traffic  overload 
protection  (ATOP)  line  load 
control  status 

Calls  blocked  by 
precedence 

Last  hours  total 

Dial  tone  delay 
(1  second) 

Last  hours  total 

Total  switch  accesses 

Last  hours  total 

Calls  completed 

Last  hours  value  for 
each  node 

TOTAL 

Number  of  such  records--10 
Total  bytes- -3 10 


TABLE  3-7.  TRUNK  GROUP  STATUS  FILE 


Number  of  such  records- -2 5 


TABLE  3-8.  THUNK  TRAFFIC  FILE 


TABLE  3-9.  CRITICAL  USER  ACCESS  STATUS  FILE 
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Number  of  such  records- -50 


The  AUTOVON  displays  are  divided  into  five  major  classes,  as  shown  on 
the  display  hierarchy  chart  (Figure  3-2).  The  major  categories  of  displays 
are  as  follows: 

•  Traffic  displays 

•  Switch  equipment  displays 

* 

•  Trunk  equipment  displays 

•  User  access  circuit  and  equipment  displays 

•  Text  and  general  information  displays 

The  information  is  arranged  hierarchically,  with  a  summary  display  of 
everything  in  the  network  (Figure  3-3)  available  at  the  top  of  the  hierarchy. 
Displays  of  progressively  greater  detail  are  provided  at  lower  levels  of  the 
hierarchy.  Figures  3-3  through  3-10  show  the  format  of  these  displays. 

The  routing  table  display.  Figure  3-10,  is  particularly  important  because 
it  supports  manual  control  of  the  routing.  When  this  display  is  active,  the 
controller  can  directly  interact  with  the  processor  to  modify  switch  routing 
tables  or  the  manner  in  which  the  tables  are  automatically  revised.  There 
is  one  display  for  each  switch  in  the  network,  and  it  displays  the  currently 
active  routing  to  each  destination  switch.  The  character  following  the  route 
indicator  shows  whether  the  routing  is  being  automatically  controlled  (blank) 
or  manually  forced  (*),  if  the  route  is  a  spill  route  ($),  and  if  the  route  is 
currently  carrying  only  primary  routed  traffic  (! ).  If  a  switch  has  been 
destination  code  cancelled,  destination  code  cancellation  (DCC)  appears 
as  its  primary  route;  and  the  remaining  routes  are  filled  with  asterisks. 
The  controller  can  modify  the  switch  routing  by  moving  the  cursor  to  a 
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Figure  3-2.  AUTOVON  Display  Hierarchy 
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Figure  3-9.  Trunk  Status  Summary  Display 
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2.4.X  OTHER  SWITCH  ROUTING  CONTROL  DISPLAYS 
2.0  SWITCH  STATUS  SUMMARY 


Figure  3-10,  Routing  Control  Display  for  Hillingdon 
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route  and  typing  over  it  with  the  name  of  another  route.  If  the  controller 
simply  wants  the  processor  to  pick  another  route,  blanks  can  be  input. 

Typing  a  blank  onto  a  manual  override  indicator  returns  the  route  to 
automatic  adaptive  control. 

The  automatic  adaptive  routing  recommended  for  AUTOVON  is  a  particularly 
simple  form.  Its  purpose  is  to  guarantee  that  there  is  an  operating  route 
available  to  critical  subscribers  homed  on  a  given  switch  as  long  as  any 
transmission  resources  are  available  to  the  switch.  As  described  in 
Section  4,  the  adaptive  routing  routine  is  exercised  at  ACOC  whenever  a 
trunk  group  failure  is  detected.  In  response  to  a  failure,  the  routine  selects 
the  next  alternate  route  from  a  preengineered  list  of  alternates,  checks  it 
for  reasonableness,  and  then  implements  it  by  sending  routing  change 
messages  to  the  switches  . 

Another  automatic  control  routine,  causing  the  automatic  inhibition  of 
alternate  routes  as  a  function  of  traffic  level,  is  also  recommended.  The 
only  phenomenon  in  a  circuit  switched  network  requiring  traffic  controls  is 
the  thrashing  phenomenon  in  which  a  large  part  of  the  network  trunking 
capacity  is  being  held  by  call  attempts  which  will  be  blocked.  It  is  brought 
on  by  heavy  traffic  either  at  a  particular  point  in  the  network  or  generally 
throughout  the  network.  When  traffic  is  heavy,  more  calls  try  multiple 
alternate  routes,  increasing  the  average  time  a  MFT/RSJ  pair  is  held  in 
the  originating  switch.  In  addition,  the  heavy  originating  load  causes  a  high 
level  of  demand  for  RSJs.  This  results  in  increasing  delays  for  tandem 
traffic  from  other  switches  in  obtaining  an  RSJ.  This  increasing  delay 
reflects  around  the  network  until  calls  start  to  time  out  waiting  for  the 
RSJ.  This  would  be  seen  as  "failure  to  receive  start  signal"  at  the 
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originating  switch.  As  the  situation  develops,  more  trunks  and  RSJs  are 
occupied  by  calls  sitting  and  waiting  for  a  distant  end  RSJ,  thereby  decreasing 
the  capacity  of  the  network  both  to  set  up  and  to  carry  traffic. 

Any  control  which  can  reduce  the  ineffective  time  that  a  call  occupies  a 
RSJ  will  delay  the  onset  of  the  thrashing  phenomenon.  An  effective  and  easy 
way  to  implement  control,  which  does  not  defeat  the  multilevel  precedence 
system,  is  automatic  inhibition  of  alternate  routes  or  primary- only  routing. 

In  this  control,  the  occupancy  of  each  trunk  group  is  sensed  over  a  very 
short  interval,  like  five  minutes.  While  this  time  span  is  much  too  short  tc 
determine  anything  about  the  underlying  statistical  process,  it  can  be  used 
to  determine  the  instantaneous  loading.  If  the  group  is  busy  over  the  time 
interval,  only  primary  routes  which  use  the  group  will  be  permitted  to  make 
attempts  on  the  group  during  the  following  interval.  Secondary  and  tertiary 
routes  which  ride  the  group  will  be  blocked  at  their  origins. 

This  control  tends  to  minimize  the  set  up  time,  without  significantly  increasing 
blocking,  by  reserving  the  remaining  group  capacity  for  primary  routed  users. 
This  allows  the  switches  to  handle  a  greater  number  of  calls  and  prevents 
tying  up  the  network  resources  while  waiting  for  a  switch.  During  the  time 
that  primary- only  routing  is  implemented,  the  blocking  probability  for  critical 
users  on  certain  routes  will  be  slightly  increased.  However,  this  increase 
is  certainly  less  than  the  increased  blocking  due  to  a  large  number  of  attempts 
at  lower  priorities  tying  up  the  switch.  This  control  is  also  applied  and 
relieved  quickly,  so  that  unnecessary  network  throttling  is  avoided. 
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This  set  of  manual  and  automatic  controls  can  be  practically  implemented 
on  the  490L  network  and  provide  sufficient  control  capability  to  maintain 
effective  operation  of  whatever  AUTOVON  resources  remain  operational  in 
the  stress  condition. 


SECTION  4 


HARDWARE  AND  SOFTWARE  FOR  CONTROL  IMPLEMENTATION 

4. 1  SUMMARY  OF  RECOMMENDED  SYSTEM  DESIGN 

The  new  hardware  recommended  as  a  result  of  this  study  is  summarized  in 
Table  4-1.  The  major  items  of  new  hardware  are  the  CRU  and  the  computer 
system  at  ACOC.  Section  4.2. 1  provides  a  detailed  description  of  the 
function  of  the  CRU  and  the  specific  capabilities  of  a  feasibility  demonstra¬ 
tion  model  being  developed  by  Rome  Air  Development  Center  (RADC).  The 
computer  system  at  ACOC  is  a  minicomputer  with  associated  peripheral 
devices.  The  components  for  the  recommended  configuration  are  shown  in 
Table  4-2. 

Software  additions  and  modifications  are  summarized  in  Table  4-3.  The 
size  estimates  for  these  subsystems  are  shown  in  Table  4-4.  Within  the 
preexisting  system  control  subsystems,  only  very  minor  changes  are 
needed.  ATEC  needs  to  be  modified  to  accommodate  communications  with 
ACOC  and  the  DSCS/CS  TCE.  The  AUTODIN  II  SNCC  is  a  duplicate  of  the 
NCC,  modified  to  relay  status  reports  to  the  CONUS  NCC.  The  RAMM  has 
a  fairly  significant  software  change  which  allows  it  to  process  switch  status 
and  traffic  data  for  transmission  to  ACOC,  manage  the  communications 
lines  to  the  ATEC  NCS,  and  actuate  controls  upon  receipt  of  valid  commands 
from  ACOC  or  the  local  controller. 
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TABLE  4-1.  SUMMARY  OF  HARDWARE  MODIFICATIONS 


System/Subsystem 

Hardware  Modification 

Remarks 

AUTODIN  II  SNCC 

None 

See  note 

RAMM 

Modified  to  provide 
three  new  I/O  ports 
for  A  CAS  data,  oper¬ 
ations  keyboard  display 
unit  (KDU),  and  ATEC 
interface. 

See  Section  4.2.2 

CRU 

New  subsystem  to  pro¬ 
vide  remote  control 
patching  capability  for 
the  DCS. 

See  Section  4. 2 . 1 . 2 

DSCS--TCE 

None 

See  note 

DSCS--NCE 

None 

See  note 

ATEC--CIS 

None 

CIS  assumed  to  have 
spare  ports  at  sites 
requiring  access. 

See  note 

ATEC--NCS 

None 

See  note 

ATEC--SCS 

None 

See  note 

ACOC  level 

New  processor  and  per¬ 
ipherals  to  support  the 
ACOC  control  functions. 

Note:  Processor  memory  augmentation  judged  not  to  be  required 
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TABLE  4-2.  ACOC  HARDWARE  COMPONENTS/PRICING 


Equipment 

Cost 

CPU 

$10,000 

Memory  256  K  bytes 

30,350 

10M  byte  moving  head  disk  and  controller 

12,700 

Magnetic  tape  drive  and  controller 

11.000 

Multiline  communication  processor  with 
line  adapters  for  3  CRT  terminals 
and  4  sync  commlines 

6,000 

CRT /keyboard /hard  copy  printer  3  @  $6,485 

19,455 

Cabinets /power  distribution/memory  battery 
backup 

3,  560 

TOTAL 

$93,065 

Optional 

Scientific  instruction  processor 

$  5,050 

Mass  storage  disk  33M  and  controller 

21,000 

Line  printer  and  adapter 

10,440 
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TABLE  4-3.  SUMMARY  OF  SOFTWARE  MODIFICATIONS 


System/Subsys  terns 

Software  Modifications 

AUTODIN  II--SNCC 

Provide  capability  to  transmit  all 

PSN  reports  received  to  NCC- CONUS. 

RAMM 

Provide  capability  to  access  and 
process  switch  status  and  traffic 
parameter  for  transmission  to  ACOC 
at  appropriate  timing  intervals. 

Provide  interface  to  ACAS  data,  an 
operations  KDU,  and  an  ATEC  node. 

DSCS--TCE 

Compute  historical  profiles  for  EIRP 
and  RSS  parameter,  file  for  local  display, 
provide  alarm  thresholds  for  operator 
alerting,  transmit  periodically  to  NCE. 

Report  earth  terminal  status  alarms 
to  ATEC-CIS  using  ATEC  10000  formats 
and  protocol. 

Report  alarm  exception  reports  to  NCE. 

DSCS--NCE 

Receive  and  file  EIRP  and  RSS  historical 
profiles  for  local  display,  transmit  to 
ACOC. 

Receive  exception  report  from  TCE  re¬ 
cord  in  data  base,  update  display  and 
transmit  to  ACOC. 

AT  EC --CIS 

Message  routing  tables  modified  to 
accommodate  messages  to  and  from  TCE, 
to  and  from  ACOC. 

ATEC--NCS 

Message  routing  tables  modified  as  in 

ATEC  CIS,  Process  TCE  alarm  message 
for  correlation  with  terrestrial  alarms, 
store  faults,  transmit  uncorrelated 
faults  to  sector. 

ATEC--SCS 

Message  routing  tables  modified  as  in 
ATEC-CIS,  transmit  and  receive  message 
from  ACOC  on  AUTODIN. 

Process  TCE  alarm  messages  from  node 
store  and  attempt  correlation  with 
terrestrial  alarms. 

ACOC/WWOLS 

New  software  system  to  perform  system 
control  functions  at  the  theater  level. 
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TABLE  4-4.  SYSTEM/SUBSYSTEM  SOFTWARE  SIZING  SUMMARY 


System /Subsystem 

Number  of 
Instructions 

Storage  (bytes) 

Program 

Data 

AUTODIN  II  SNCC 

2  5H 

375 

-- 

RAMM 

955H 

15.015 

2  50 

230A 

DSCS--TCE 

23  5H 

3,  525 

100 

DSCS--NCE 

210H 

3.150 

200 

ATEC— CIS 

3  OH 

450 

ATEC--NCS 

275H 

4.125 

ATEC--SCS 

235H 

3.525 

ACOC/WWOLS 

2002  5H 

* 

*  See  Table  4-5. 


The  software  size  for  the  new  ACOC/WWOLS  processor  is  shown  in 
Table  4-5.  A  description  of  the  software  making  up  this  estimate  is  in 
reference  2  and  Sections  4.4. 1.1,  4. 4. 2.1,  and  4. 4. 3.1  of  this  report. 
Table  4-6  shows  an  estimate  of  the  data  base  size  for  the  data  base 
described  in  Sections  2  and  3  of  this  report. 
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TABLE  4-5.  MEMORY  REQUIREMENT  FOR  ACOC 


Element 

Resident 

Support 

Overlay 

Largest 

Functional 

Overlay 

Total 

Occupancy 

(bytes) 

Theatre 

15.750 

23,475 

9.750 

48,975 

Connectivity 

15,750 

32,245 

47,850 

95.845 

AUTOVON  control 

15,750 

27,375 

18,000 

61,125 

Operating  system 

22,000 

System  pool 

20,000 

Data  base  management 

20,000 

62,  000  Bytes 

Total  Memory  Required 

157,  845  Bytes 
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TABLE  4-6.  THEATRE  DATA  BASE  SIZING  (concluded) 


4.2  HARDWARE  REQUIREMENTS  FOR  CONTROL  IMPLEMENTATION 

4.2.1  The  Automated  Patch  Network- -CRUs 

4.2. 1.1  Functional  Description  of  the  CRU--Previous  reports  have  alluded 
to  the  future  existence  of  CRUs  at  station  level  which  would  automate  the 
patching  function.  Although  these  devices  are  not  required  as  part  of  the 
proposed  network  control,  they  have  been  addressed  as  to  their  impact  on 
control  implementation.  A  short  description  of  a  feasibility  demonstration 
model  of  a  CRU  currently  being  developed  by  RADC  is  given  here  as  it  relates 
to  system  control. 

The  CRU  is  designed  to  provide  remotely  controlled  patching  of  DCS  circuits 
and  groups.  The  unit  performs  this  function  by  time-division  manipulation 
of  channel  data  words.  Thus,  it  can  provide  channel  or  group  patching 
without  requiring  all  levels  of  multiple  hierarchy  to  be  present  for  every 
group.  It  can  carry  out  this  patching  activity  without  local  site  manning  due 
to  its  computer  interface  capability  with  remote  control  sites. 

Inside  the  CRU,  the  groups  presented  to  the  ports  are  broken  down  into 
channels  and  the  resulting  channel  data  stored  in  the  reassignment  memories. 
The  channel  data  is  reconfigured  into  groups  by  selectively  reading  the 
reassignment  memories.  The  sequence  of  reading  the  memories  (and  hence 
the  channel  reassignments)  is  programmed  into  the  CRU  hardware  by  the 
CRU  control  computer.  Frame  bits  are  added  to  the  newly  assembled 
groups  and  the  result  outputted  from  the  CRU.  In  this  manner,  a  single 
channel  from  any  input  group  may  be  output  onto  any  output  group.  Both 
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T1  and  tri- services  tactical  communication  system  (TRI-TAC)  groups  can 
be  bandied  in  this  way.  In  addition,  Tl  to  TRI-TAC  group  conversions  are 
possible  in  the  CRU  to  provide  DCS/TRI-TAC  interfaces. 

The  level  of  the  CRU  in  the  DCS  multiplex  hierarchy  is  shown  in  Figure  4-1. 
The  CRU  will  interface  DCS  transmission  facilities  at  the  group  and  channel 
levels.  TRI-TAC  interface  will  take  place  on  group,  channel,  and  subchannel, 
levels.  The  CRU  will  be  able  to  make  non-blocking  patches  at  all  levels.  In 
addition,  the  CRU  will  be  able  to  multiplex  locally  incoming  Tl  and  TRI-TAC 
channels  into  groups.  The  CRU  will  also  act  as  an  interface  unit  between  the 
DCS  and  TRI-TAC  multiplex  hierarchies  by  allowing  channels  from  either 
family  to  be  re-formatted  for  the  other's  group  multiplex. 

Figure  4-2  depicts  the  configuration  of  the  transmission  plant  using  CRU. 

The  CRU  replaces  the  equal  level  patching  bay  at  the  station  level.  Trans¬ 
mission  facilities  that  enter  the  station  terminate  on  the  CRU  ports  from 
which  they  are  time- division  patched  to  the  appropriate  output  from  the 
station.  The  connectivity  will  reside  in  the  CRU  time  switching  pattern 
rather  than  a  patch  bay  of  cables. 

Control  for  the  CRU  is  normally  effected  via  the  ATEC  CIS.  This  unit  will 
interface  with  the  CRU's  control  computer  over  a  150  baud  link  providing  all 
levels  of  system  control  access  to  the  CRU's  control  computer.  Commands 
such  as  patching  new  connectivity  for  altr outing,  CRU  port  redefinition, 
connection  of  spare  CRU  port  equipment,  and  testing  of  CRU  modules  will 
pass  over  the  ATEC/CRU  interface.  Alternatively,  the  CRU  control  computer 
can  be  accessed  via  the  station  CTS  or  from  a  dedicated  KDU  if  no  CTS  is 
available.  Thus  the  CRU  is  controllable  from  automatic  and  manual,  remote 
and  local  control  interfaces. 
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Figure  4-1.  CRU  in  the  DCS  Multiplex  Hierarchy 


One  important  effect  that  CRUs  will  have  upon  the  DCS  is  increased  available 
connectivity.  In  the  current  network,  patching  of  channels  can  take  place  only 
at  locations  where  the  channels  have  a  voice  frequency  (VF)  appearance.  In 
order  to  provide  full  patching  capability  at  a  station,  the  station  would  require 
2  second-level  multiplexers,  16  channel  banks,  and  some  number  of  sub¬ 
channel  multiplexers  for  every  link  terminating  at  the  station.  With  the 
CRU,  full  patching  capability  is  achieved  without  this  number  of  multiplexers 
at  each  station.  In  addition,  the  coding  and  decoding  noise  that  would  be 
created  by  channel  bank  coding  of  VF  circuits  is  avoided  due  to  the  coded 
time-division  patching  of  the  CRU. 

With  full  patching  capability  at  each  station,  the  trunks  normally  described 
in  the  DCS  network  are  all  shortened  to  one  link  for  patching  purposes.  The 
drop  of  a  channel  will  still  require  a  channel  bank,  but  each  circuit  will 
only  require  one  at  each  end  rather  than  at  every  patch  station.  This  increase 
in  connectivity  will  prevent  route  "backhauling"  as  is  currently  seen  in  the 
DCS.  It  will  also  simplify  the  altroute  search  algorithms  described  in 
report  3. 

4.2. 1.2  The  CRU  Cost  Estimate--A  budgetary  cost  of  50  CRUs  has  been 
estimated.  The  basis  for  this  estimate  was  obtained  from  data  gathered 
from  the  RADC  contract  on  which  three  feasibility  models  are  being  developed. 
The  configuration  and  functions  currently  being  incorporated  in  the  feasibility 
models  are  those  selected  for  the  cost  estimate.  Parts  lists  are  available 
for  the  various  components  which  make  up  the  system  and  have  been  used 
to  arrive  at  parts  costs.  Figure  4-3  shows  a  side  view  of  the  rack  assembly 
and  depicts  the  components  that  have  been  included  in  this  cost  estimate. 

The  overall  cost  of  a  single  unit  is  basically  a  function  of  the  number  of 


group  frames  that  are  required  in  the  actual  deployment  in  specific  DCS 
stations.  To  determine  the  deployment  configurations  required,  the  DCS 
stations  in  Europe  were  examined.  The  results  are  in  Table  4-7.  Each 
group  frame  can  accommodate  up  to  40  groups.  Each  station  was  examined 
to  determine  the  DCS  requirements  using  the  multiplex  configuration  and 
DCS  connectivity  projected  for  1985.  A  group  frame  was  allocated  for  every 
30  T1  groups  allowing  10  additional  inputs  to  be  connected  (TRI-TAC  groups 
or  other  channels).  The  production  quantity  of  50  includes  the  37  configura¬ 
tions  requiring  two  or  more  group  frames  plus  13  which  require  only  a 
single  group  frame.  It  is  assumed  that  the  initial  deployment  will  include 
all  of  the  major  DCS  stations.  The  cost  of  each  CRU  configuration  has 
been  computed  taking  advantage  of  a  production  quantity  of  50  units  requiring 
a  total  of  105  group  frames. 

The  cost  is  based  on  the  following  assumptions: 

•  Parts  have  been  selected  and  prices  based  on  components 
meeting  full  military  specifications. 

•  Production  costs  do  not  include  acquisition  non-recurring 

costs  such  as  preparation  of  documentation,  drawings,  schematics, 
manufacturing  assembly  drawings,  manufacturing  assembly 
procedures,  and  various  board,  unit,  system  checkout  and  test 
procedures,  and  operating  or  test  software. 

•  All  boards  are  tested  automatically,  but  the  non-recurring 
cost  to  develop  this  capability  is  not  included  in  the  production 
price. 

•  All  prices  are  FOB  at  manufacturer's  facility. 


TABLE  4-7.  CRU  CONFIGURATIONS 
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•  All  costs  include  manufacturing  and  engineering  overhead 
(90%),  general  administration  (17%),  and  fee  (10%). 

•  All  costs  are  quoted  assuming  a  one-year  production  effort 
with  a  mid-point  of  January  1980. 

The  components  which  make  up  the  costs  are  shown  in  Table  4-8  together 
with  the  total  price  of  a  CRU  configured  with  a  single  group  frame. 
Additional  configuration  costs  are  obtained  by  adding  an  increment  of 
$15,  942  for  each  additional  group  frame  required.  This  cost  is  the  sum  of 
the  group  frame  and  a  modular  power  supply  assembly.  A  cost  of  a 
configuration  #5  CRU  is  therefore  $102,842. 

The  composite  total  production  cost  of  50  CRUs  is: 

Configuration 


Number 

Quantity 

Unit  Cost 

Extended  Cost 

1 

13 

39,074 

507,  962 

2 

26 

55,016 

1,430,416 

3 

6 

70, 958 

425,  748 

4 

3 

86, 900 

260, 700 

5 

2 

102,842 

205,  684 

TOTAL  2,830,  510 


4.2.2  AUTOVON  Control  Hardware 

4.2.2. 1  Switch  Site  Hardware  Candidates- -The  design  of  the  490L  switch 
does  not  adequately  support  real-time  system  control.  External  hardware 
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TABLE  4-8.  INDIVIDUAL  COST  COMPONENTS 


is  required  to  sense  the  status  of  the  switch  and  to  implement  control 
actions  received  from  a  centralized  control  facility.  The  candidates  for 
switch  site  hardware  are  the  following: 

•  ACAS  (AUTOVON  Centralized  Alarm  System) 

•  TDCS  (Traffic  Data  Collection  System) 

•  RAMM  (Rapid  Access  Maintenance  Monitor) 

•  New  developments 

The  ACAS  senses  the  state  of  several  parameters  (see  Table  3-2)  via 
individual  sense  leads  from  the  switch.  As  the  system  is  currently  used, 
the  sensed  data  is  blocked  and  transmitted  to  ACOC  over  dedicated  75  baud 
telemetry  lines  every  two  seconds.  The  data  is  read  into  latches  at  ACOC 
and  displayed  on  a  panel  of  pilot  lights.  There  is  no  processing  or  memory 
capability  associated  with  ACAS.  Because  the  display  is  a  direct  display 
of  switch  state,  rather  than  an  alarm  display,  it  is  difficult  for  controllers 
to  interpret.  It  is  therefore  not  useful  as  a  component  of  system  control. 
The  status  information  sensed  at  the  switch  is,  however,  quite  basic  to 
system  control.  This  data  should  be  collected  and  preprocessed  by  the 
switch  site  processor  so  that  ACOC  can  be  informed  of  any  significant 
events  implied  by  it. 

TDCS  is  a  minicomputer  based  system  intended  for  collection  of  long-term 
engineering  data.  The  processor  is  a  Lockheed  SUE  computer  interfaced 
to  the  switch  memory  and  several  status  leads.  TDCS  operates  in  one  of 
three  modes:  rapid  memory  reload,  routine  data  collection,  or  quick-look 
data  collection.  Because  of  the  processing  load,  TDCS  can  only  operate 
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in  one  mode  at  a  time.  Rapid  memory  reload  provides  a  means  to  load  the 
switch  memory  from  magnetic  tape.  It  has  been  the  most  used  mode  in  the 
past,  but  this  function  is  being  superceded  by  the  RAMM  which  has  more 
extensive  memory  manipulation  capabilities. 

In  the  data  collection  modes,  TDCS  collects  extensive  traffic  and  status 
information  from  the  switch  as  shown  in  Table  4-9  (Reference  6).  Most 
of  the  detailed  traffic  information  is  derived  by  tracking  the  operation  of  the 
switch  RSJs.  This  tracking  requires  a  large  amount  of  detailed  data 
manipulation  and  accounts  for  the  load  which  restricts  TDCS  to  one  mode  at 
a  time.  When  operating  in  data  collection  mode,  TDCS  writes  the  data  onto 
a  magnetic  tape.  It  also  has  a  capability  to  automatically  dial  up  a  processor 
at  ACOC,  and  dump  the  data  at  1200  baud. 

TDCS  seems  to  be  subject  to  several  problems  which  prevent  its  use  as  a 
system  control  component.  Reference  7  claims  that  TDCS  is  a  very 
temperamental  piece  of  equipment  because  of  not  operating  a  large  portion 
of  the  time  and  operating  with  questionable  accuracy  the  rest  of  the  time. 

If  this  availability  problem  is  not  solved,  TDCS  cannot  be  considered  for 
future  applications.  The  SUE  minicomputer  is  no  longer  manufactured  or 
supported  by  Lockheed,  so  maintenance  problems  will  be  increasing  as  the 
equipment  ages.  The  protocol  used  on  the  dialup  telemetry  does  not  have 
significant  error  protection.  In  the  past,  this  has  prevented  the  use  of  the 
telemetry  as  the  circuits  are  not  good  enough  to  provide  error-free  data 
transfer.  Finally,  the  man-machine  interface  at  ACOC  is  not  usable  for 
real-time  control  since  it  merely  dumps  a  large  block  of  data  without  any 
alarm  thresholding,  formatting,  or  data  control  capabilities. 


TABLE  4-9.  TDCS  DATA  COLLECTION  ITEMS 


Lead 

Lead 

Troffic  Data  by  Trunk  Group  (110  Groups) 

DTMF  Receiver  (15  Receivers 

Originating  attempts 

Out- of- service  count 

X 

Terminations 

Out- of- service  duration 

X 

Preemptions 

All  DTMF  Receivers 

Non- Preemptive  overflow 

Attempts  count 

Preemptive  overflow 

Usage 

X 

Usage 

X 

Overflow  count 

All  trunks  busy  count  (30  Groups) 

X 

MF  2/6  Transceiver  (15  Transceivers) 

All  trunks  busy  duration  (30  Groups) 

X 

Out-of- service  count 

X 

Traffic  Data  by  Destination 

Out-of- service  duration 

X 

(200  Destinations) 

All  MF  2/6  Transceivers 

Voice  grade 

Attempts  count 

Special  grade 

I'sage 

X 

Counts 

Overflow  count 

Local  attempts 

All  Register-Senders  Busy 

Line  permanent  signal 

Count 

X 

(time  outs) 

Duration 

X 

False  start 

All  DTMF  Receivers  Busy 

Partial  Dial 

Count 

X 

Timed  out 

Duration 

X 

Call  abandoned 

All  MF  2/6  Transceivers  Busy 

Intro-office  attempts 

Count 

X 

(local  terminations) 

Duration 

X 

Local  Voice  Grade  Calls 

Heavy  Traffic 

Local  Special  Grade  Calls 

Count 

X 

Incoming  Attempts 

Duration 

X 

Tandem  Attempts 

Pilot  Make  Busy  (30  Pilots) 

Trunk  Permanent  Signal 

C  ount 

X 

(time  outs) 

Duration 

X 

Preemption  K'xercised 

Line  Load  Gontrol  Class 

Voice  grade 

(3  Classes  A,  R,  and  C) 

Special  grade 

Count 

X 

No  Start  Signal  Indicator 

Duration 

X 

Preemption  Failed,  Voice  Grade 

Switch  Marker  (2  Markers) 

Preemption  Failed,  Special  Grade 

Out-of- service  count 

X 

Routine  Overflow 

Out- of- service  duration 

X 

Voice  grade 

Logic  (3  Logics) 

Special  grade 

Out-of- service  count 

X 

Traffic  Data  by  Register- Sender 

Out- of- service  duration 

X 

(24  Register-Senders) 

DSA  Position/Link  (20  I.inks) 

Attempts 

Position  count 

X 

Usage 

X 

Position  usage 

X 

Out-of-service  count 

X 

Link  group  busy  count 

X 

Out- of- service  duration 

X 

Link  group  busy  usage 

X 

DSA  Marker  (2  markers) 

All  links  busy  count 

X 

Out- of- service  count 

X 

All  links  busy  duration 

X 

Out- of- service  duration 

X 

Memory  (2  memories) 

Out- of- service  count 

X 

Out- of- service  duration 

X 

\nswer  Time  Recorder 

Calls  sampled 

X 

Calls  answered 

X 

Calls  not  answered 

Traffic  Data  by  DSA  Class  (5  Classes) 

Attempts 

Overload  counts 

X 

Hampering  any  modification  of  TDCS  is  the  fact  that  the  software  design 
uses  a  custom  executive  (no  operating  system  is  used),  and  the  coding  is 
directly  done  at  the  absolute  assembly  level.  Therefore,  any  modifications 
would  be  difficult  and  costly. 

In  spite  of  all  its  deficiencies,  TDCS  provides  extensive  traffic  collection 
capabilities.  If  the  difficulties  could  be  overcome,  it  would  be  very  valuable 
to  use  the  RSJ  tracking  capabilities  of  TDCS  to  collect  basic  traffic  data  as 
an  input  to  a  local  system  control  processor.  This  would  relieve  the  system 
control  processor  of  a  major  computational  burden.  However,  because  of 
the  difficulties  experienced  with  TDCS  in  the  past,  that  recommendation 
cannot  be  made.  If  the  maintenance  problems  are  solved,  TDCS  should  be 
considered  for  low-level  traffic  parameter  sensing. 

The  newest  piece  of  AUTOVON  equipment  is  the  rapid  access  maintenance 
monitor  (RAMM).  The  RAMM  is  a  replacement  for  the  original  electro¬ 
mechanical  maintenance  monitor.  Its  primary  purpose  is  to  interpret 
trouble  card  data  from  the  switch  BITE  in  order  to  simplify  the  maintenance 
and  repair  tasks.  It  also  provides  a  capability  to  reload  the  switch  memory 
from  disk.  The  RAMM  consists  of  a  Data  General  NOVA  3D  minicomputer, 
96K  words  of  memory,  moving  head  disk,  tapes,  and  hardware  to  interface 
with  the  switch.  The  system  is  run  under  DG's  RDOS,  a  well  known  fore¬ 
ground/background  multitasking  operating  system.  All  current  programs 
are  written  in  FORTRAN,  and  current  tasks  occupy  about  33%  of  the 
processor's  time. 

Because  the  RAMM's  primary  purpose  is  aiding  the  diagnosis  of  switch 
malfunctions,  it  is  a  superior  source  of  switch  status  information.  Since 


120 


it  can  read  and  write  in  the  switch  memory,  it  has  the  capability  to  collect 
traffic  data  and  to  modify  routing  tables,  translation  tables,  etc.  It  has  an 
efficient  multitasking  operating  system  and  has  the  capability  to  collect  all 
sources  of  switch  data  and  communicate  with  a  local  supervisor  and  with 
ACOC. 


4. 2 . 2 . 2  Recommended  Hardware  Configuration- -The  recommended  hard¬ 
ware  configuration  for  system  control  of  AUTOVON  is  shown  in  Figure  4-4. 
It  is  based  upon  use  of  the  RAMM  as  the  primary  information  processing 
system  at  the  switch  site.  ACAS  telemetry  lines  are  connected  directly  to 
the  RAMM,  rather  than  to  telemetry  circuits.  This  provides  the  basic 
traffic  monitoring  capability  to  the  RAMM.  It  may  be  redundant  with  other 
interfaces  already  present  in  the  RAMM,  but  this  could  not  be  determined 
from  available  RAMM  documentation.  If  this  interface  turns  out  to  be 
redundant,  there  is  no  need  to  use  any  ACAS  equipment. 

A  new  keyboard /display  unit  has  been  added  to  the  RAMM  for  use  by  the 
operations  supervisor.  From  this  KDU,  the  operations  supervisor  can 
manipulate  switch  tables  to  implement  controls  and  can  communicate  with 
ACOC  via  text  messages.  Also  added  is  a  2400  baud  commline  into  the 
ATEC  NCS.  The  NCS  port  was  selected  rather  than  a  150  baud  CIS  port 
for  the  following  reasons: 

•  There  is  a  NCS  colocated  with  every  490L  switch. 

•  Switches  are  located  in  large  stations  whose  CIS  ports 
are  heavily  loaded  otherwise. 

•  150  baud  is  only  minimally  adequate. 
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The  ATEC  system  does  no  processing  of  AUTOVON  information  but  does 
provide  message  switching  service  for  telemetering  to/from  ACOC. 

If  TDCS  is  proven  practical,  it  can  also  be  interfaced  to  the  RAMM  using 
the  TDCS  1200  baud  port,  adding  another  1200  baud  port  to  RAMM.  No 
other  hardware  modifications  to  RAMM  are  needed. 

The  hardware  required  at  ACOC  is  the  system  control  processor  shared 
with  other  system  control  functions.  It  may  be  desirable  to  dedicate  a 
keyboard /display  to  the  AUTOVON  function,  but  otherwise  the  hardware  is 
as  described  in  reference  2 . 

4.2.2. 3  Hardware  Cost  Estimate- -The  recommended  modifications  to  the 
Rapid  Access  Maintenance  Monitor  are  depicted  in  Figure  4-4.  These 
modifications  include  an  operations  keyboard  display  terminal  for  handling 
text  messages  to  and  from  the  ACOC  System  Control  Processor,  determin¬ 
ing  490L  switch  status,  and  modifying  the  switch  memory.  Modifications 
also  include  processor  interfaces  to  accommodate  the  new  KD  terminal,  a 
75  baud  asynchronous  data  input  to  collect  ACAS  data,  and  a  2400  baud 
synchronous  ATEC  interface  for  upwards  reporting.  The  CRT  selected  is 
a  Data  General  Model  6053  alphanumeric  video  display  terminal  with 
detachable  keyboard.  This  unit  provides  selectable  speed  (110  to  19. 2K 
baud),  standard  EIA  or  20ma  interface,  11  key  data  entry  pad,  8  function 
keys,  64  character  set  (ASCII  upper  case),  24  line  x  80  character  screen, 
direct  cursor  positioners,  character  blink,  and  provisions  for  optical  hard 
copy  printer.  The  unit  is  priced  at  $1990  each.  The  interface  requirements 
can  be  satisifed  with  a  single  multi-line  communication  interface.  A  Data 
General  Model  4243  interface  has  been  selected.  This  interface  provides 
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Figure  4-4.  Hardware  Modifications  to  RAMM 


a  functional  combination  of  a  Model  4241  four-line  asynchronous  subsystem 
plus  a  Model  4242  one-line  synchronous  controller  subsystem.  The  4243 
is  priced  at  $2700  each.  The  total  added  hardware  cost  for  each  RAMM 
subsystem  is  $4690.  The  total  cost  for  nine  490L  switches  and  the  associ¬ 
ated  RAMM  subsystem  is  (9  x  $4690)  $42,210. 

4.3  COMMUNICATIONS  REQUIREMENTS  FOR  TRANSMISSION  CONTROL 

4.3.1  Overview 

Communications  requirements  for  implementing  altrouting  are  determined 
by  the  nature  and  location  of  the  activities  involved.  The  station  level  of  the 
system  control  hierarchy  is  the  level  at  which  patching  is  actually  imple¬ 
mented  since  it  is  the  only  level  that  actually  connects  to  the  transmission 
system.  The  altroute  and  normalization  algorithms  are  performed  at 
ACOC  for  the  following  reasons: 

•  ACOC  has  full  visibility  of  all  data  needed  to  perform 
altrouting  including  a  data  base,  ATEC  fault  isolation 
reports,  and  DSCS/CS  status  reports. 

•  No  excessive  message  traffic  is  created  by  performing 
altroute  generation  at  ACOC. 

•  Making  all  altroute  generation  occur  at  the  highest  level  which 
has  the  real-time  area  data  base  makes  it  easier  to  maintain 
data  base  consistency. 


•  Processor  time  is  likely  to  be  more  available  at  ACOC 
than  at  lower  levels. 
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The  series  of  implementation  steps  for  altrouting  is  shown  in  flow  chart 
form  in  Figure  4-5.  The  process  begins  with  ATEC  or  DSCS/CS  detecting 
a  fault  condition  and  isolating  the  report  to  some  specific  equipment  and 
location.  This  output  leads  to  assigning  the  fault  to  a  station  for  ETR 
estimation  and  eventual  repair.  The  circuit  control  office  (CCO)  notifies 
the  user  that  his  service  is  out  of  order.  The  output  of  fault  isolation  and 
ETR  estimation  is  a  fault  file  entry  to  the  data  base  for  the  service  affected. 
This  data  base  update  is  sent  to  sectors  and  ACOC.  Should  the  ETR  be 
short  enough  that  data  base  update  and  eventual  altrouting  would  not  be 
implemented  before  repair,  the  ACOC  stores  the  fault  report  and  takes  no 
action  on  it.  Establishing  the  threshold  level  on  the  ETR  for  this  decision 
can  be  made  with  the  help  of  the  implementation  time  analysis  presented  in 
Report  3  (Section  2.8). 

When  the  decision  is  made  to  altroute,  the  altroute  routines  are  put  into 
action  to  synthesize  the  altroutes.  The  patching  messages  required  for  the 
altroute  are  automatically  generated  and  the  new  data  base  entry  for  the 
altroute  created.  A  listing  of  the  altroute  is  then  presented  to  the  altroute 
controller  for  approval.  Rejection  at  this  stage  must  be  accompanied  with 
some  controller  action  (data  base  update  or  search  parameter  changes)  so 
that  a  second  run  of  the  algorithms  will  yield  a  new  altroute.  When  approval 
is  finally  given,  the  patching  messages  are  sent  out  to  the  patching  stations 
via  ATEC  telemetry.  At  this  point,  the  controllers  at  the  patching  stations 
concur  or  reject  the  plan  concerning  their  specific  patching  and  preemption 
actions.  This  step  is  needed  in  order  to  guarantee  that  late  or  incorrect 
fault  reports  concerning  the  alternate  route  are  considered  just  before 
patching  occurs. 
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Figure  4-5.  Altroute  Implementation  Interfacing 
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Figure  4-5.  Altroute  implementation  Interfacing  (continued) 


Rejection  of  an  altroute  patch  plan  at  a  station  must  be  accompanied  by 
some  explanation  of  why  the  plan  fails  at  a  particular  station.  If  proper 
cooperation  is  being  given,  these  reports  should  deal  exclusively  with  new 
fault  status  information  that  ACOC  has  not  considered.  Thus,  data  base 
updating  at  ACOC  and  rerunning  the  altroute  synthesis  will  follow. 

When  all  patching  stations  concur  with  an  altroute  plan,  ACOC  will  send  an 
acknowledgment  to  all  patching  stations  to  implement  patches.  The  data 
base  links  to  the  new  altroute  records  are  made  at  ACOC  to  reflect  the 
altroute's  presence.  These  data  base  updates  are  then  transmitted  to 
sectors  for  AT  EC  data  base  updates. 

The  normalization  activity  is  basically  a  reverse  of  the  altrouting;  returning 
circuits  or  trunks  to  their  normal  transmission  facilities  form  an  altroute 
configuration.  As  shown  in  Figure  4-6  the  reporting  of  status  data  triggers 
this  activity. 

The  activity  begins  for  normalization  when  all  faults  on  a  service's  normal 
route  are  removed  or  all  preemptions  made  to  a  service's  normal  route 
are  deleted.  The  normalization  routine  operates  to  determine  if  normalization 
is  possible  and  generates  the  data  required  to  patch  the  normal  route  and 
update  the  data  base.  Report  3  gives  the  details  of  this  routine.  Upon 
generation  of  the  normalization  plan,  the  area  controller  will  inspect  it  for 
accuracy  and  then  send  it  to  the  patching  stations.  Each  station  will  see  the 
plan  as  it  refers  to  its  part  of  the  route  and  be  allowed  to  respond  to  ACOC. 
This  gives  the  stations  closest  to  the  real  route  a  final  chance  to  examine 
the  area  computer's  analysis  of  the  action.  If  exceptions  result  due  to  some 
data  in  error  or  late  to  ACOC,  the  station  will  submit  this  timely  data  to 
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Figure  4-6.  Normalization  Activity  (continued) 
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ACOC  for  the  area  controller  to  correct  his  data  base.  If  the  area  controller 
still  sees  the  possibility  of  normalization,  the  normalization  routine  is  run 
again  to  generate  a  new  plan  for  station  submission.  Once  all  stations  have 
accepted  the  normalization  plan,  the  area  controller  can  respond  by  allowing 
all  patches  to  be  made  and  data  base  updates  to  be  finally  implemented  to 
show  the  route  normalization. 

4.3.2  The  Altroute  Message  Formats 

4. 3.2.1  Fault  Status  Reports  —  Figure  4-7  presents  a  fault  report  format 
for  messages  sent  up  the  ATEC  hierarchy.  This  format  follows  the  one 
presented  in  Report  2  (p.  5-39).  From  this  type  of  report  message,  the 
fault  file  entries  and  links  of  the  ACOC  data  base  could  be  generated  and 
the  fault  made  visible  in  the  connectivity  data  base. 

4. 3.2.2  Altroute  Patching  Message  Formats- -Once  an  altroute  has  been 
synthesized  by  the  algorithms,  ACOC  sends  messages  to  the  stations  involved 
in  the  patching  operation.  The  node  and  sector  to  which  these  instructions 
are  sent  act  only  as  message  relay  points. 

To  develop  the  altroute  message  formats,  a  specific  example  is  used  (see 
Figure  4-8).  This  altroute  was  discussed  in  Report  3  as  one  of  the  response 
time  scenarios  (Section  2.8).  In  this  example  the  circuit  6D23  (using  the  last 
four  characters  of  CCSDs)  has  failed  due  to  link  M0063  failure.  The  circuit 
is  altrouted  by  preempting  the  two  circuits  shown  on  the  LKF  to  DON  to  FEL 
route.  LKF  must  patch  the  main  distribution  frame  (MDF)  appearance  of  the 
circuit  to  a  new  channel  bank  port.  FEL  patches  the  altroute  back  into  the 
original  route.  The  station  at  DON  preempts  two  circuits  by  patching  C784 
to  WCCA.  Station  at  RMN  is  not  involved  in  the  altrouting  messages  even 
though  the  altroute  passes  through  it. 

i 
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INITIAL  FAULT  REPORT:  Characters 

ATEC  message  header  21 

Message  Identifier*  2 

Fault  report  number  4 

Circuit,  trunk  or  link  ID  9 

Submitting  location  4 

Terminating  locations  8 

Location  of  fault  4 

Time  out  8 

Degree  of  degradation  3 

Cause  of  fault  (Computer  generated  message. 

Should  define  the  service's  segment 

that  is  effected  by  this  failure)  20 

ATEC  message  trailer  2 

Total  =  85 


FOLLQM-UP  FAULT  REPORT: 

ATEC  message  header  21 

Message  identifier  2 

Fault  report  number  4 

Reference  fault  report  number  4 

Submitting  location  4 

Location  of  fault  4 

Time  of  this  report  8 

Degree  of  degradation  3 

ETR  4 

Narrative  field  57 

ATEC  message  trailer  2 

Total  =  103 


♦Identifies  the  message  for  display  format  processing. 

Figure  4-7.  Format  of  the  Fault  Status  Reports 
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Figure  4-8.  Example  of  a  Circuit  Altroute  Patch 


To  develop  the  patching  message  formats  for  the  stations,  first  design  a 
station  display  that  will  give  the  tech  controller  the  information  needed  for 
the  patching.  The  area  controller  will  also  have  a  display  to  review  the 
altroute.  Starting  with  the  area  display  will  facilitate  designing  the  station 
display  by  making  one  a  subset  of  the  other. 

Figure  4-9  shows  the  area  controller's  altroute  patching  summary  display. 
The  first  line  is  not  a  patch,  but  actually  lists  the  circuit  being  altrouted. 
The  stations  given  as  "to"  and  "from"  indicate  the  stations  between  which 
the  altroute  must  exist  in  order  to  restore  service.  The  fields  following 
the  station  names  (LKF  and  FEL)  indicate  the  link,  supergroup,  group,  and 
channel  used  to  enter  these  stations  from  the  segment  of  the  normal  route 
that  is  now  failed.  The  remaining  lines  give  actual  patches  to  establish  the 
altroute.  The  preempted  circuit  CCSD  is  first  listed  along  with  its  RP  for 
reference  to  the  controllers.  The  station  making  the  listed  patch  along  with 
the  status  of  the  patch  message  to  that  station  is  given  next.  Finally,  the 
actual  patch  is  given.  The  two  station  entries  give  the  stations  connected 
by  the  patch  being  made  at  the  patching  station.  The  link,  supergroup,  and 
channel  data  for  the  patch  refers  to  the  appearance  of  the  preempted  circuit 
at  the  patching  station. 

We  chose  to  use  link,  supergroup,  group,  and  channel  data  to  identify  the 
patch  rather  than  a  channel  on  a  trunk.  Names  of  trunks  may  change  on  a 
transmission  link,  but  the  transmission  system  multiplex  names  always 
remain  the  same  during  service  changes. 
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The  display  contains  two  operator  entry  fields.  The  "SEND  MESSAGES" 
field  automatically  sends  the  patching  messages  to  the  appropriate  patching 
stations.  The  messages  will  then  enter  a  "TEMP"  status  mode  indicating 
that  the  altroute  is  only  temporarily  made.  The  patching  stations  have  the 
plan  and  are  evaluating  it.  The  stations  will  then  send  their  response  to  the 
area  controller  and  these  will  appear  in  the  patching  station  status  field 
next  to  each  station’s  name.  If  all  stations  accept  the  plan,  the  operator  can 
enter  a  command  into  the  "COMMAND"  field  to  send  final  implement  messages 
to  stations  and  update  the  data  bases.  If  rejections  occur,  the  stations  will 
send  exception  reports.  The  area  controller  may  act  on  suggestions  of  these 
exception  reports  to  make  data  base  changes  or  change  parameters  in  the 
algorithm  and  then  re-run  the  altroute  search.  He  may  also  decide  to  drop 
the  altroute  job  altogether.  All  these  commands  can  be  entered  into  the 
field  of  his  display  to  complete  the  altroute  control  activity. 

The  PATCH  ID/ LINE  can  be  used  to  uniquely  identify  a  message  sent  from 
any  station.  Each  altroute  is  assigned  a  new  two  digit  sequence  making  up 
the  first  two  numbers  in  the  LINE.  The  last  digit  identifies  a  specific 
patch  command  per  that  altroute.  A  three- character  ID  field  (see  Figures 
4-10,  4-11,  and  4-12)  gives  a  station  identification  to  a  line.  Responses 
from  the  stations  using  both  the  station  ID  and  LINE  identifiers  will  give 
the  area  controller  full  knowledge  of  the  station  responding  and  the  item  on 
a  particular  altroute  in  question. 

Figure  4-11  shows  a  message  sent  to  a  patching  station  which  is  also  a 
terminal  station  of  the  altrouted  circuit.  Note  that  this  and  other  station 
displays  are  exact  subsets  of  the  area  display.  The  first  line  identifies 
the  altrouted  circuit.  The  actual  patch  appears  in  the  second  line.  Note 
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ALTROUTE 

PATCHING 

INSTRUCTIONS 

PATCH  ID/LINE 

PREEMPTED 

RP 

FROM 

CCSD 

♦LKF/010 

6D23 

ID 

LKF/M0063/A301 

LKF/011 

JDQV  C784 

00 

LKF/MDF  (6D23) 

MESSAGE  STATUS: 

(TEMP) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe 
( 

SEND  RESPONSE: 

(  ) 

Figure  4-10. 

Langerkopf  Patching  Display 

ALTROUTE 

:  PATCHING 

INSTRUCTIONS 

PATCH  ID/LINE 

PREEMPTED 

CCSD 

RP 

FROM 

♦DON/011 

6D23 

ID 

LKF 

DON/ 01 2 

JDQV  C784 

00 

LKF/M0671/A410 

JUBV  WCCA 

00 

MESSAGE  STATUS:  (TEMP) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe  exception. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-11.  Donnersberg  Patching  Display 


TO 

FEL 

D0N/M0671/A410 


exception. 

) 


TO 

FEL 

FEL/M0372/B120 
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ALTROUTE  PATCHING  INSTRUCTIONS 

PATCH  ID/LINE 

PREEMPTED 

CCSD 

RP 

FROM 

TO 

*FEL/010 

6D23 

ID 

LKF 

FEL/M0063/A301 

FEL/013 

JUBV  WCCA 

00 

D0N/M0298/A824 

FKT/M0070/A301 

MESSAGE  STATUS:  (TEMP  ) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe  exception. 

<  ) 

SEND  RESPONSE:  (  ) 

Figure  4- 12 .  Feldberg  Patching  Display 

that  MDF  refers  to  the  main  distribution  frame  at  this  circuit  drop  station. 
The  other  ,vTO"  patch  gives  the  multiplex  identification  of  a  trunk  to  DON  to 
which  the  MDF  is  to  be  patched  for  the  altroute.  The  message  status  field 
is  an  output  field  to  tell  the  tech  controller  when  to  actually  implement  the 
patch.  In  "TEMP"  mode,  the  controller  knows  that  the  area  controller  has 
just  sent  out  the  plan  and  is  awaiting  station  responses  to  it.  When  all 
stations  finally  agree  on  a  plan,  the  message  status  changes  to  "VERIFIED" 
to  indicate  that  the  altroute  patch  should  now  actually  be  made.  A  message 
indicating  the  response  of  the  station  to  ACOC  is  entered  into  "ALTROUTE 
ACCEPTABLE"  with  an  exception  message  if  rejected.  The  "SEND 
RESPONSE"  sends  the  answers  automatically  to  ACOC. 
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Figures  4-11  and  4-12  show  other  examples  of  messages  to  patching  stations. 
Station  DON  is  a  new  station  along  the  circuit's  route  and  patches  onto  two 
preempted  circuits.  FEL  was  the  station  where  re-entry  to  the  normal 
route  was  found  to  be  possible  and  gives  as  its  "TO"  patch  the  first  trunk 
along  the  original  route  that  attaches  to  the  altroute. 

Figure  4-13  finally  gives  a  format  and  sizing  of  the  altroute  patching  message. 
Only  variable  data  is  sent.  The  field  sizes  for  the  display  will  decompose 
the  character  string  into  the  data  items  and  provide  the  display  delimiters. 
The  ATEC  format  is  used  and  only  one  block  is  needed  per  station  per 
altroute.  The  field  identifying  the  message  type  is  used  by  the  message 
processor  to  interpret  the  string  of  raw  characters  in  the  message  field  and 
set  up  the  proper  display  for  the  controller.  Two  characters  assumed  here 
allow  for  a  number  of  message  types  to  be  formatted  for  display. 

Characters 


ATEC  message  header  21 

Message  identifier  *  2 

Display  line  1— Altrouted  circuit  27 

Display  line  2— Patch  50 

ATEC  message  trailer  2 

Total  =  100 


*  Identifies  this  as  a  patching  message  in  order  to  set  up  the  proper 
display  formats  and  indicates  message  status  to  the  controller. 

Figure  4-13.  The  Patching  Message  Format  for  Circuits 
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The  patching  messages  for  trunk  altrouting  are  demonstrated  with  the 
example  of  Figure  4-14.  The  displays  are  shown  in  Figures  4-15,  4-16, 
4-17  and  4-18.  These  displays  are  logical  extensions  of  the  circuit  patching 
messages  and  are  not  discussed  in  detail  here.  The  message  format  and 
sizing  is  given  in  Figure  4-19. 

4.  3. 2. 3  Normalization  Patching  Mess  ages --Following  the  method  for 
establishing  the  altroute  patching  messages,  normalization  messages  will  be 
derived  by  working  an  example.  Figure  4-20  shows  the  normalization 
patching  for  the  circuit  altroute  example  given  earlier.  The  area  controller 
would  be  given  the  display  of  Figure  4-21  from  the  normalization  routine  to 
allow  him  to  review  the  plan.  The  patching  format  follows  the  altroute 
patching  format  in  order  to  use  the  controller's  familiarity  with  the  altroute 
display.  The  first  line  gives  the  circuit  whose  altroute  is  being  removed 
and  whose  normal  route  is  being  restored.  The  following  lines  give  the 
patches  needed  to  establish  the  normal  route  and  re-connect  the  preempted 
circuits  used  to  establish  the  altroute.  Each  station  has  two  patch  items  to 
carry  out  these  actions.  The  line  labelling,  message  status,  and  response 
field  are  the  same  in  function  and  format  as  described  earlier  for  the 
altroute  patching  displays. 

Figures  4-22,  4-23  and  4-24  show  station  displays  for  patching  as  subsets 
of  the  area  display.  The  first  line  again  denotes  the  circuit  whose  route  is 
being  normalized.  The  response  fields  here  are  also  duplicates  of  the 
altroute  displays  and  work  in  the  same  manner. 
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FAILED  LINK 


Figure  4-14.  Example  of  a  Trunk  Altroute 
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SUMMARY  ALTROUTE  PATCHING  INSTRUCTIONS 


PATCH 

ID/LINE 

PREEMPT 

PATCH 

STATION 

RP 

FROM 

TO 

*/010 

44JMQ2 

lowest  2A 

LKF/M0063/A1 

FEL/M0063/A1 

-/Oil 

spare 

LKF(TEMP) 

none 

LKF/CB(44JMQ2) 

D0N/M0671/A3 

-/012 

44CMD2 

DON(ACC) . 

highest  3B 

LKF/M0671/43 

FEL/M0372/A4 

-/013 

44CMD2 

FEL(REJ) 

highest  3B 

D0N/M0298/B1 

FEL/CB(44JMQ2) 

EXCEPTIONS:  (  )  Enter  conmand  to  enter  update  data  base  (DB), 
algorithms  parameter  modification  and  re-run 
mode  (RR),  drop  the  altroute  action  (DR), 
finally  implement  altroute  (FI)  or  edit  station 
exception  reports  (ER). 

SEND  MESSAGES:  (  ) 

Figure  4-15.  Area  Altroute  Message  Summary  Display 
ALTROUTE  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

PREEMPT 

R? 

FROM 

TO 

♦LKF/010 

440MQ2 

lowest  2A 

LKF/M0063/A1 

FEL 

LKF/011 

spare 

none 

LKF/CB(44JMQ2) 

D0N/M0671/A3 

MESSAGE  STATUS:  (  TEMP  ) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe  exception. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-16.  Langerkopf  Patching  Display 


145 


/ 


ALTROUTE  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

PREEMPT 

RP 

FROM 

TO 

♦D0N/010 

44MMQ2 

lowest  2A 

LKF 

FEL 

D0N/012 

44CMD2 

highest  3B 

LKF/M0671/A3 

FEL/M0372/A4 

MESSAGE  STATUS:  (  TEMP  ) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe  exception. 

(  ) 

SEND  RESPONSE:  (  ) 


Figure  4-17.  Donnersberg  Patching  Display 


ALTROUTE  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

PREEMPT 

RP 

FROM 

TO 

♦FEL/010 

44MMQ2 

lowest  2A 

LKF 

FEL/M0063/A1 

FEL/013 

44CMD2 

highest 

D0N/M0298/B1 

FEL/CB(44JMQ2) 

MESSAGE  STATUS: 

(  TEMP  ) 

ALTROUTE  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  up  to  80  characters  to  describe  exception. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-18.  Feldberg  Patching  Display 
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Characters 


21 

2 
27 
34 
2 

Total=  86 

♦Identifies  the  message  type  for  display  format  generation  and  message 
status  state. 

Figure  4-19.  Patching  Message  Format  for  Trunks 

The  route  normalization  displays  for  trunk  normalization  are  given  in  an 
example  in  Figure  4-25.  The  displays  resulting  from  that  example  which 
define  the  message  content  are  found  in  Figures  4-26,  4-27,  4-28  and  4-29. 
These  displays  are  direct  extentions  of  the  circuit  normalization  displays 
described  earlier. 


ATEC  message  header 

Message  Identifier* 

Display  line  1— altroute  trunk 
Display  line  2— Patch 
ATEC  message  trailer 


Finally,  the  message  formats  and  sizes  for  these  normalization  patch 
messages  are  given  in  Figure  4-30  for  both  the  circuit  and  trunk  cases. 


SUMMARY  NORMALIZATION  PATCHING  INSTRUCTIONS 
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Figure  4-21.  Area  Normalization  Patching  Summary  Display 


NORMALIZATION  PATCHING  INSTRUCTIONS 


CIRCUIT  FROM  TO 

DTXX  6D23  LKF/M0063/A301  FEL 

DTXX  6D23  LKF/MDF(6D23)  FEL/M0063/A301 

JDQV  C784  MUL/M0378/A101  DPN/M0671/A410 

MESSAGE  STATUS:  (  TEMP  ) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SEND  RESPONSE:  (  ) 


Figure  4-22.  Langerkopf  Normalization  Patching  Display 
NORMALIZATION  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

CIRCUIT 

FROM 

TO 

♦D0N/010 

DTXX  6D23 

LKF 

FEL 

DON/ 01 3 

JDQV  C784 

LKF/M0671/A410 

LSY/MZZZZ/B222 

DON/014 

JUBV  WCCA 

RSN/M0092/A714 

FEL/M0372/B120 

MESSAGE  STATUS:  (  TEMP  ) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-23.  Donnersberg  Normalization  Patching  Display 


PATCH  ID/LINE 

♦LKF/010 

LKF/011 

LKF/012 


NORMALIZATION  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

CIRCUIT 

FROM 

TO 

♦FEL/010 

DTXX  6D23 

LKF 

FEL/M063/A301 

FEL/015 

DTXX  6D23 

LKF/M0063/A3Q1 

FKT/M0070/A301 

FEL/016 

JUBV  WCCA 

D0N/M0298/A824 

RMN/M0298/B612 

MESSAGE  STATUS:  (TEMP) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-24.  Feldberg  Normalization  Patching  Display 
4.4  SOFTWARE  REQUIREMENTS  FOR  CONTROL  IMPLEMENTATION 
4.4.1  Software  Requirements  for  Altr outing 

4.  4. 1. 1  Description  of  the  Software- -The  description  of  additional  software 
to  implement  the  altrouting  algorithms  is  presented  in  this  section.  A 
large  part  of  the  software  required  to  support  the  altrouting  control  is 
described  in  Report  2  (Sections  4. 1  and  4.2)  where  functional  flows  for 
data  base  updating  and  status  reporting  are  laid  out  and  sized.  Functional 
flows  of  these  tasks  have  been  given  and  the  software  elements  to  perform 
these  tasks  are  included  in  the  software  hierarchy. 
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Figure  4-26.  Area  Route  Normalization  Patching  Summary  Display 


NORMALIZATION  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

TRUNK 

FROM 

TO 

♦LKF/010 

44JMQ2 

LKF/M0063/A1 

FEL 

LKF/011 

440MQ2 

LKF/CB(44JMQ2) 

FEL/M0063/A1 

MESSAGE  STATUS:  (TEMP) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-27.  Langerkopf  Route  Normalization  Patching  Display 


NORMAL IZATION  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

TRUNK 

FROM 

TO 

♦D0N/010 

44JMQ2 

LKF 

FEL 

DON/012 

44CMD2 

D0N/CB(44CMD2) 

FEL/M0372/A4 

MESSAGE  STATUS:  (TEMP) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SEND  RESPONSE:  (  ) 

Figure  4-28.  Donnersberg  Route  Normalization  Patching  Display 
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NORMALIZATION  PATCHING  INSTRUCTIONS 


PATCH  ID/LINE 

TRUNK 

FROM 

TO 

♦FEL/010 

44JMQ2 

LKF 

FEL/M0063/A1 

FEL/013 

44JMQ2 

LKF/M0063/A1 

FEL/CB(44JMQ2) 

FEL/014 

44CMD2 

D0N/M0298/B1 

FEL/CB(44CMD2) 

MESSAGE  STATUS:  {  ) 

NORMALIZATION  ACCEPTABLE?  (  ) 

EXCEPTIONS:  Enter  exceptions  in  less  than  80  characters. 

(  ) 

SENO  RESPONSE:  (  ) 

Figure  4-29.  Feldberg  Route  Normalization  Patching  Display 

The  altrouting  control  function  is  defined  in  terms  of  the  functional  flow 
method  of  Report  2.  From  such  a  description,  additional  software  elements 
are  defined  and  sized  and  can  be  entered  into  the  overall  software  hierarchy 
(see  Figure  4-31).  The  flow  chart  representation  of  the  altrouting  control 
activity  in  Figure  4-6  will  guide  this  functional  flow  generation. 

Figures  4-32  and  4-33  show  functional  flows  for  key  altroute  implementation 
activities  that  have  not  already  been  analyzed  in  Report  2.  The  flow  format 
of  Report  2  was  used  in  the  analysis.  The  functional  sub-elements  in  the 
control  action  hierarchy  are  seen  in  Figure  4-32.  This  is  essentially  the 
hierarchy  of  Report  2  with  several  additions  regarding  the  altrouting  control 
and  normal  routing  normalization  action  (to  be  discussed  later).  The  third 
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CIRCUIT  NORMALIZATION 


Characters 


ATEC  message  header  21 
Message  type  identifier  2 
Display  line  1— Circuit  restored  to  normal  routing  29 
Display  line  2— Normalization  1  38 
ATEC  message  trailer  2 

ATEC  message  header  21 
Display  line  3— Normalization  2  38 
ATEC  message  trailer  2 

Total  «  153 


TRUNK  NORMALIZATION 

ATEC  message  header  21 

Message  type  Identifier  2 

Display  line  1— Trunk  restored  to  normal  routing  25 

Display  line  2— Normalization  1  22 

Display  line  3— Normalization  2  22 

ATEC  message  trailer  2 

Total  »  94 


Figure  4-30.  Route  Normalization  Patching  Messages 
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Figure  4-32.  Connectivity  Control- -Altroute  Generation 
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Figure  4-33.  Connectivity  Control- -Altroute  Implementation 
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level  control  actions  added  basically  represent  the  aitroute  main  calling 
routing  (as  aitroute  control)  and  a  normalization  routine  interface  (as 
route  normalization  control).  These  control  levels  interface  ATEC  reporting 
to  determine  the  aitroute  work  load  due  to  reported  failures  and  normalization 
load  for  reported  repairs  and  fault  file  deletions.  The  actual  aitroute  search 
package  appears  in  the  fourth  or  algorithm  level  as  does  the  normalization 
routine.  The  access  to  trunks  and  fault  files  is  finally  entered  into  the 
fifth  or  data  base  interface  level  to  permit  full  data  base  access  and  manipu¬ 
lation  for  the  algorithms. 

4.4. 1.2  Software  Sizing/Cost — The  software  required  to  implement  the 
automatic  aitroute  algorithms  has  been  sized  in  a  manner  similar  to  the 
previous  software  sizing  task  reported  in  Report  2.  Each  software  module 
has  been  sized  in  terms  of  estimated  lines  of  HOL  code  required  to  imple¬ 
ment  the  functions.  Program  occupancy  is  based  on  a  ratio  of  15  bytes  of 
storage  for  each  HOL  instruction.  Table  4-10  summarizes  the  software 
sizing  for  aitroute  implementation  according  to  the  modules  defined  in  the 
software  hierarchy  chart.  The  individual  routines  that  make  up  the 
altrouting  functions  have  been  individually  sized  and  are  included  in 
Appendix  C.  The  aitroute  control  module  includes  the  main  calling  routines 
and  the  common  file  handling  logic.  The  aitroute  search  module  includes 
the  circuit  and  trunk  altrouting  routines,  the  cost  calculating  routines,  the 
circuit  matching  routine,  and  the  goal  station  definition  routine.  The 
implementation  modules  are  revised  estimates  from  the  previous  sizing 
tasks,  and  the  two  file  control  modules  are  new  modules  required  to 
support  the  algorithm.  The  3490  lines  of  code  translate  to  a  cost  of  582 
man  days  of  labor. 
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TABLE  4-10.  SOFTWARE  SIZING  FOR  ALTROUTE  IMPLEMENTATION 


_ L-. 


4.4.2  Software  for  Route  Normalization 


4. 4.2. 1  Description  of  the  Software- -The  control  functional  flow  for  the 
normalization  of  routing  is  described  here  in  terms  of  the  control 
actions  from  Figure  4-6.  The  normalization  activity  requires  some  new 
control  actions  in  Figure  4-6.  The  "Route  Normalization  Routine"  is  the 
normalization  algorithm  described  in  Report  3.  The  "Route  Normalization 

I 

Control"  function  must  interface  the  ATEC  reporting  activity  to  key  into 
fault  file  removal  due  to  equipment  repairs.  The  notification  of  this  action 
should  result  in  the  normalization  routines  being  called  into  action. 

The  new  control  actions  "CCSD  Normalization  Implementation"  and  "Digroup 
Normalization  Implementation"  act  to  generate  displays,  send  messages 
and  coordinate  responses  to  messages  involved  in  normalization  patch 
coordination  with  stations. 

Since  status  reporting  has  already  been  described  in  the  functional  flow  of 
Report  2,  the  support  for  normalization  data  base  updates  has  already  been 
addressed  there.  The  remaining  normalization  control  activities  are  shown 
in  functional  flow  form  in  Figures  4-34  and  4-35.  These  activities  follow 
from  the  flow  chart  of  Figure  4-6  and  are  similar  to  the  altroute  flows. 

4. 4.2.2  Software  Sizing/Cost — The  software  required  for  normalization  of 
normal  routing  after  an  altroute  has  been  implemented  has  been  sized  and  is 
summarized  in  Table  4-11.  The  routine  associated  with  route  normalization 
has  been  estimated  in  more  detail  in  Appendix  C.  The  1010  lines  of  code 
required  to  implement  these  functions  translates  to  152  man  days  of  labor. 
This  cost  increment  is  added  to  the  total  software  effort  required  to  imple¬ 
ment  the  ACOC-WWOL  system  control  processor. 
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Figure  4-34.  Connectivity  Control- -Normalization  Plan  Generation 


TABLE  4-11.  SOFTWARE  SIZING  FOR  NORMALIZATION  IMPLEMENTATION 


■  ■  ~*r  f  ■ 


4.4.3  Software  Requirements  for  AUTOVON  Control  Implementation 

\ 

*  *  ■ 

4.4.3. 1  Software  Description- -The  software  needed  to  implement  the 
recommended  AUTOVON  controls  consists  of  a  set  of  routines  supporting 
automatic  and  manual  changes  to  switch  routing  tables.  Manual  modification 
of  routing  tables  is  supported  by  an  interactive  CRT  display  process.  The 
operator  can  call  up  the  routing  tables  for  any  switch;  and  by  positioning  * 
the  cursor  at  any  given  entry  and  typing  in  a  new  entry,  the  routing  is 
modified.  The  software  at  ACOC  therefore  accepts  cursor  and  key  commands 
when  the  routing  table  display  is  up.  T^ese  commands  are  interpreted  as 
routing  modifications  and  a  routing  table  change  message  is  sent  to  the 
switch  RAMM  via  ATEC.  Software'' in  the  RAMM  accepts  the  command 
input  and  appropriately  modifies  the  switch  memory. 

Automatic  control  software  is  similarly  straight-forward.  There  are 
basically  two  automatic  routing  algorithms:  the  adaptive  routing  algorithm 
and  the  primary- only  routing  algorithm.  The  adaptive  routing  algorithm 
is  executed  any  time  a  trunk  group  failure  is  detected. 

The  adaptive  routing  algorithm  operates  in  a  special  section  of  the  data  base 
which  has  the  following  data  for  each  source  destination  pair  of  switches: 

•  A  prioritized  list  of  alternate  routes.  This  list  will  have 
at  least  one  route  using  each  trunk  group  exiting  the  source, 
and  one  route  using  each  trunk  group  entering  the  destination 
switch,  so  that  there  will  be  an  operational  route  on  the  list 
as  long  as  the  switch  is  not  isolated. 

I 
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•  The  status  of  each  alternate- -failed,  active,  primary- only, 
active,  standby. 

•  A  code  conversion  indicator,  for  those  routes  where  code 
conversion  is  required  to  prevent  ring- around- the  rosey. 

This  data  base  is  engineered  on  a  long-term  basis  and  is  subject  to  changes 
as  a  result  of  new  facilities  on  changing  traffic  patterns. 

When  a  trunk  group  fails,  the  software  searches  through  the  data  base  to 
find  each  route  riding  the  failed  trunk  group.  For  each  route  found,  the  next 
alternate  on  the  list  is  checked  to  see  if  it  is  redundant  with  a  currently 
active  route.  For  example,  a  section  of  the  list  for  LKF-SCH  would  be  as 
follows : 


LKF-SCH 

LKF-FEL-SCH 

LKF-DON-SCH 

LKF-HIN-FEL-SCH 

In  normal  operation,  the  first  three  routes  are  active  for  this  source 
destination  pair.  If  the  direct  route  failed,  the  adaptive  routing  algorithm 
would  examine  the  LKF-HIN-FEL-SCH  route  and  see  that  it  is  redundant 
with  the  LKF-FEL-SCH  route.  When  the  next  alternate  is  found  to  be 
redundant,  as  was  the  case  here,  that  alternate  is  not  activated;  and  the 
next  member  of  the  list  is  examined. 
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In  the  case  of  LKF-SCH  with  the  direct  route  failed,  all  other  members  of 
the  list  will  be  redundant  since  there  are  only  three  trunk  groups  to  SCH 
and  all  three  are  in  either  active  routes  or  failed.  In  this  situation,  the 
source  destination  pair  will  be  left  with  only  two  routes.  However,  if  the 
LKF-FEL  trunk  group  had  failed,  it  could  be  replaced  by  the  LKF-HIN-FEL- 
SCH  route. 

When  the  routine  finds  failed  routes  or  new  routes  to  activate,  it  forms 
messages  to  the  affected  switch  RAMMs  to  modify  their  routing  tables.  This 
keeps  the  switch  from  wasting  time  on  failed  routes  and  continually  provides 
the  best  routing  alternatives.  A  pre- engineered  list  was  chosen  instead  of 
a  search  procedure  for  AUTOVON  for  the  following  reasons: 

•  The  number  of  alternatives  for  routing  is  quite  limited. 

•  There  may  be  traffic-related  reasons  why  roundabout  routes 
may  be  given  higher  priority  than  more  direct  routes. 

•  The  list  process  needs  only  minimal  trunk  group  status  data 
to  make  its  decisions. 

•  Traffic  studies  have  shown  that  real-time  selections  of  routes 
based  on  instantaneous  traffic  measurements  do  not  provide 
better  service  than  pre- engineered  routes. 

Therefore,  this  algorithm  provides  near  optimum  service  with  minimum 
information  sensing  and  processing. 

The  second  major  automatic  control  algorithm  is  the  primary-routing- only 
algorithm.  This  algorithm  starts  with  a  special  measurement  by  the  RAMM. 
Every  five  minutes,  the  RAMM  accumulates  the  percent  of  the  time  that 
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the  all  trunks  busy  lead  is  active  for  each  group  and  makes  a  threshold 
decision  when  the  trunk  is  heavily  loaded.  Typical  threshold  values  would 
be  80%  to  90%  of  the  time.  When  the  threshold  measurement  is  taken,  a 
message  is  sent  to  ACOC  containing  the  busy/no  busy  decision  for  the  trunk 
groups . 

The  software  at  ACOC  searches  its  data  base  of  routing  tables  to  find  all 
non-primary  routes  which  ride  each  trunk  group  marked  busy.  It  then  sends 
messages  to  the  originating  switches  of  these  routes  to  deactivate  the  routes. 
Similarly,  the  algorithm  searches  for  secondary  and  tertiary  routes  which 
had  been  temporarily  deactivated  because  of  a  busy  trunk  which  had  become 
not  busy  during  the  previous  measurement  interval.  These  routes  are 
reactivated  via  messages  to  the  switches. 

Routes  which  are  temporarily  deactivated  because  of  traffic  loading  are  not 
replaced  by  the  adaptive  routing  algorithm  since  they  will  be  reactivated  as 
soon  as  the  traffic  decreases.  They  are  known  to  be  non-primary  under  an 
operational  primary  route.  If  the  primary  route  should  happen  to  fail,  the 
adaptive  routing  algorithm  would  make  the  secondary  route  a  primary  which 
would  reactivate  it  regardless  of  the  traffic  situation. 

A  simpler  alternative  algorithm  could  be  implemented  at  the  switch  itself 
without  any  telemetering  of  messages.  Switches  could  detect  and  not  use 
heavily  loaded  trunk  groups  for  other  than  primary  routed  originating  traffic. 
Since  AUTOVON  operates  with  originating  office  control,  all  tandem  traffic 
appears  to  be  primary  routed,  so  simpler  algorithms  would  not  affect  tandem 
traffic.  Since  the  primary  goal  of  this  algorithm  is  to  prevent  multiple 
attempts  on  transatlantic  routes  during  a  traffic  overload,  thereby  reducing 
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intra- European  signalling  traffic  and  switch  processing  loads,  this  simpler 
version  of  primary  routing  is  not  sufficient.  The  primary  routing  restric¬ 
tion  needs  to  operate  on  tandem  as  well  as  originating  traffic,  thereby 
requiring  the  algorithm  described  here. 

4. 4. 3.2  Software  Sizing  and  Cost- -The  software  modifications  or  additions 
to  accomplish  AUTOVON  control  and  implementation  are  made  to  two 
subsystems,  the  RAMM  and  the  ACOC-WWOLS  system  control  processor. 
The  recommended  modifications  to  the  RAMM  software  are  listed  in 
Table  4-12.  A  total  of  955  FORTRAN  and  230  assembly  level  instructions 
are  required.  Based  on  the  assumptions  made  in  Section  1.3.3,  this 
translates  to  178  man  days  of  labor  to  make  these  modifications. 

The  increment  of  software  added  to  the  ACOC-WWOLS  system  control 
processor  is  the  software  to  accommodate  the  two  new  algorithms  described 
above.  These  two  algorithms  require  an  additional  400  lines  of  HOL  code. 
This  addition  adds  67  man  days  of  effort  to  the  total  system  control  processor 
tasks  summarized  in  Section  1.3.3. 
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TABLE  4-12.  RAMM  SOFTWARE  ADDITIONS/MODIFICATIONS 


Program  Module 

Number  of 
Instructions 

Program 

(Bytes) 

Obtain  switch  status  parameters 

25H 

375 

Build  status  message  and  queue 

22  5H 

3375 

Obtain  traffic  parameter 

25H 

375 

Processor  traffic  parameter  for 
periodic  transmission 

75H 

1125 

Build  traffic  parameter  message 
and  queue 

75H 

1125 

Operations  KD  command /message 
processor 

175H 

2625 

AT  EC  port  command /message 
processor 

120H 

1800 

RAMM  system  software  interface 

150H 

22  50 

ATEC  message  I/O  driver 

50H 

750 

KD  message  I/O  driver 

35H 

525 

Output  message  protocol  handler 

150A 

450 

Input  message  protocol  handler 

80A 

240 

TOTALS 

955F/230A 

15015 

H  ■  HOL  (FORTRAN) 
A  =  Assembly  level 
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GLOSSARY 


ACAS 

AUTOVON  centralized  alarm  system 

ACOC 

Area  communications  operations  center 

AT  EC 

Automated  technical  control 

ATOP 

Automatic  traffic  overload  protection 

AUTODIN 

Automatic  data  interchange  network 

AUTOVON 

Automatic  voice  operated  network 

AUTOSEVOCOM 

Automatic  secure  voice  communication  network 

BCD 

Binary  coded  decimal 

BPS 

Bits  per  second 

CIS 

Communications  interface  subsystem 

CCO 

Circuit  control  office 

CCSD 

Command  circuit  service  designator 

CONUS 

Continental  United  States 

CRT 

Cathode  ray  tube 

CRU 

Channel  reconfiguration  unit 

CS 

Control  segment 

DCC 

Destination  code  cancellation 

DCS 

Defense  communications  system 

DEFCON 

Defense  condition 

DSCS 

Defense  satellite  communication  system 

DTMF 

Dual  tone  multiple  frequency 

EIRP 

Effective  isotropic  radiated  power 

ETR 

Estimated  time  of  repair 

FDM 

Frequency  division  multiplex 

GOS 

Grade  of  service 

HOL 

Higher  order  language 
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GLOSSARY  (concluded) 


IM 

KDU 

LOS 

MAS 

MDF 

MF 

MFT 

NCC 

NCE 

NCS 

OCE 

OM 

PSN 

RAMM 

RAN 

RP 

RSJ 

RSS 

SCS 

SCRAN 

SNCC 

TCE 

TDCS 

TRI-TAC 

TTY 

VF 

WWOLS 


Inlet  multiplexer 
Keyboard  display  unit 
Line  of  sight 

Measurement  acquisition  subsystem 

Main  distribution  frame 

Multiple  frequency 

Multiple  frequency  transceiver 

Network  control  center 

Network  control  element 

Nodal  control  subsystem 

Operational  control  element 

Outlet  multiplexer 

Packet  switching  node 

Rapid  access  maintenance  monitor 

Reassignment  network 

Restoral  precedence 

Register  sender  junctor 

Received  signal  strength 

Sector  control  subsystems 

Subchannel  reassignment  network 

Subnetwork  control  center 

Terminal  control  element 

Traffic  data  collection  system 

Tri- services  tactical  communication  system 

Teletype 

Voice  frequency 

World  wide  on-line  system 
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EXAMPLES  OF  ALTROUTING  ALGORITHM  OPERATION 

A.  1  INTRODUCTION 

This  appendix  will  present  some  detailed  altrouting  examples  using  the 
altrouting  algorithms  developed  in  Report  3  of  this  study.  The  examples 
will  use  the  European  DCS  configuration  as  of  1979.  Specific  failures  will 
be  assumed  and  the  resulting  altrouting  job  queue  will  be  defined.  Some 
of  the  circuit  altroute  groups  and  trunks  in  the  queue  will  be  altrouted  and 
the  details  of  the  algorithm's  steps  outlined  in  the  process.  The  purpose 
of  these  examples  is  to  further  clarify  the  altrouting  algorithm's  operation 
and  to  estimate  the  algorithm's  run  time  for  real  altroutes. 

A. 2  ASSUMPTIONS 

We  will  require  several  assumptions  to  be  made  in  order  that  the  problem 
is  well  defined  from  the  algorithm's  viewpoint.  The  assumptions  of  impor¬ 
tance  are: 

DCS  Connectivity 

In  order  to  use  the  data  base  available  on  network  connectivity,  the  mid- 
1980's  European  DCS  backbone  model  must  be  modified.  Figure  A-l  shows 
the  backbone  to  be  used  as  it  was  derived  from  current  1979  connectivity 
data.  The  main  difference  between  this  model  and  the  1980's  deployment 
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INDEX  TO  SITE  ABBREVIATIONS 


ADN  =  Adenau,  Ger. 

ANS  =  Ansbach,  Ger. 

BAN  =  Bann,  Ger. 

BDH  =  Brandhof,  Ger. 

BFM  =  Botley  Hill  Farm,  U.K. 
BHR  =  Baumholder,  Ger, 

BNA  =  Ben  Ahin,  Bel. 

BOV  =  Bovingdon,  U.K, 

BRY  *  Barkway,  U.K. 

BSN  =  Bonstetten,  Ger, 

BTL  »  Breitsol,  Ger. 

BUN  =  Bruggen,  Ger. 

CDW  =  Cold  Blow,  U.K. 

CIM  *  Cima  Gallina,  IT. 

CLO  =  Coltano,  IT. 

CRO  =  Croughton,  U.K. 

CRS  »  Christmas  Common,  U.K, 
ONK  *  Dunkirk,  U.K. 

DON  =  Donnersberg,  Ger. 

FEL  3  Feldberq,  Ger, 

FKT  =  Frankfurt,  Ger, 

FLQ  =  Flobecq,  Bel, 

FZM  =  Friolzheim,  Ger. 

GTB  *  Great  Bromley,  U.K, 

HDG  =  Heidelberg,  Ger, 

HDM  =  Heidenheim,  Ger, 

HIN  =  Hillingdon,  U.K, 

HKV  =  Hoek  Van  Holland,  Neth. 
HOU  =  Houtem,  Bel. 

HPG  =  Hohenpeissenberg,  Ger. 
HST  =  Hohenstadt,  Ger. 

HUM  =  Humosa,  Sp. 

HYE  =  High  Wycombe,  U.K. 


KSL  =  Koenigstuhl,  Ger. 

LAG  =  Lago  di  Patria,  IT. 

LDN  =  Landstuhl ,  Ger. 

LEC  =  Le  Chenoi,  Bel. 

LEV  =  Levkas,  Gr. 

LKF  =  Langerkopf,  Ger. 

LSY  =  Lindsey,  Ger. 

MAM  »  Marti esham  Heath,  U.K. 
MBA  =  Mt.  Limbara,  Sar. 

MCA  =  Mt.  Corna,  IT. 

MHN  =  Mannheim,  Ger. 

MRA  =  Martina  Franca,  IT. 

MRE  =  Mt.  Verglne,  IT. 

MTC  =  Mt.  Cimone,  IT. 

MTS  =  Mt.  Serra,  IT. 

MUL  »  Muhl,  Ger. 

NBG  =  Nuernberg,  Ger. 

NPS  »  Naples,  IT. 

PAG  =  Paganella,  IT, 

PMS  =  Pirmasens,  Ger. 

RMN  =  Rhein  Main,  Ger. 

SCH  =  Schoenfeld,  Ger. 

SGT  *  Stuttgart,  Ger. 

SHW  *  Schwanberg,  Ger. 

SPA  =  Spa  Mai  champs,  Bel. 

STN  =  Stein,  Ger. 

STO  =  Stocksberg,  Ger. 

SWN  =  Schwetzingen,  Ger. 

VHN  =  Vaihingen,  Ger. 

WBG  *  Wurzberg,  Ger. 

WEZ  =  Westrozebeke,  Ger. 

WMS  =  Worms,  Ger. 

ZUG  =  Zugspitze,  Aus. 


Figure  A-l.  Example  Network  Connectivity  (concluded) 
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model  is  the  eastern  Germany  area- -the  outer  path  from  Stuttgart  to 
Breitsol  has  been  modified,  and  Frankfurt  now  appears  in  the  backbone  on 
a  key  path  from  Breitsol  to  Koenigs tuhl. 

Patching  Compatibility 

The  determination  of  whether  a  preempting  circuit  can  patch  into  another 
circuit's  channel  depends  upon  the  types  of  channels.  The  distinction  between 
voice  and  TTY  channels  is  clearly  identified  by  the  circuit  type  classification 
in  the  data  base  (Reference  8,  DCAC  310-65-1,  Section  7).  Difference  among 
TTY  channels  are  the  data  rates  which  influence  the  modulation  and  phase 
equalization  of  the  channel.  Voice/TTY  distinctions  will  be  used  to  deter¬ 
mine  patching  compatibility  between  channels  when  a  preemption  is  made. 

We  assume  that  the  voice  and  TTY  circuits  will  appear  at  equal  level  patch 
bays  at  the  patching  stations.  This  guarantees  that  signal  level  and 
signalling  mode  are  consistent  for  patching  once  the  voice/TTY  and  data 
rate  compatibilities  are  determined. 

Patching  trunks  onto  spare  groups  or  preempted  trunks  will  be  done  at  the 
group  distribution  frame.  All  frequency  division  multiplex  (FDM)  groups 
should  be  in  the  same  channel  multiplex  frequency  band  at  this  patch  bay 
to  allow  any  patching  combinations. 

Altroute  "Cost"  Method 


The  desirability  of  an  altroute  in  the  altroute  search  algorithms  of  Report  3 
was  determined  by  assigning  "costs  "  to  each  altroute  segment  selected. 
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Those  costs  were  selected  as: 

•  Route  mileage 

•  Number  of  patches 

•  RPs  of  preempted  circuits 

•  Transmission  link  type  and  reliability 

These  examples  will  use  the  first  three  of  these  costs  in  selecting  a  desirable 
route.  The  transmission  cost  item  is  not  evident  without  inputs  from  other 
sources.  The  'heuristic  cost"  for  these  examples  will  simply  be  the  estimate 
of  altroute  mileage  for  the  unknown  altroute  segment. 

The  calculation  of  route  mileages  can  be  made  from  the  network  model  of 
Figure  A-l.  Figure  A-l  lists  route  mileages  for  all  links  in  the  network. 

The  estimate  of  the  mileage  of  the  unknown  altroute  segment  is  made  per  the 
algorithm  of  Report  3  (Section  2.6.4).  The  "paths"  used  in  that  algorithm 
are  identified  from  Figure  A-l  as  any  link  or  series  of  links  which  have 
two- link  stations  for  all  but  the  end  stations.  For  example,  the  links 
M0305,  M0216,  and  M0217  define  a  "path"  in  the  context  of  the  algorithm. 

The  patching  cost  is  added  to  the  other  costs  whenever  a  new  preemption  is 
made  and  patched  to  the  altroute.  To  cost  the  preemption  of  a  circuit  with 
a  particular  RP,  a  numerical  value  was  assigned  to  every  RP  class  (see 
Figure  A-2).  The  numerical  assignments  were  made  to  increase  exponen¬ 
tially.  The  reason  for  this  scaling  is  to  represent  the  unequivocal  dominance 
of  one  RP  over  lower  RPs. 
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RP 

Preemption  Cost 

RP 

1A 

1000 

2F 

IB 

720 

2G 

1C 

520 

2H 

ID 

370 

21 

IE 

270 

IF 

190 

3A 

1G 

140 

3B 

3C 

2A 

100 

2B 

77 

4A 

2C 

60 

4B 

2D 

46 

2E 

36 

00 

Preemption  Cost 


28 

22 

17 

13 

10 

5 

2 

1 

.3 

0 


Figure  A-2.  Preemption  Cost  vs  RP 

Finally,  the  scale  factors  used  to  combine  the  costs  are  determined.  The 
scale  factors  are  chosen  so  that  equally  important  costs  weigh  equally  in 
the  cost  sum.  Mileage  will  be  the  reference  in  these  examples  and  carry 
a  scale  factor  of  one.  The  RP  cost  scale  was  selected  to  have  scale  factor 
one  also;  a  route  extension  of  100  miles  is  worth  avoiding  preemption  of  a 
2A  circuit.  The  patching  scale  factor  of  50  is  selected  to  make  100  miles 
of  route  extension  equal  to  adding  two  additional  patching  stations  to  a  route. 
The  cost  is  calculated  by: 

COST  *  (route  mileage)  +  50*  (number  of  patches) 

+  (sum  of  preempted  circuit  RPs) 
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A.  2  EXAMPLE  1 


The  failure  of  the  radio  tower  on  link  M0902  (Houtem  to  Swingate)  occurs, 
and  the  ETR  is  found  to  be  three  hours.  This  duration  of  outage  on  the 
carried  trunks  means  that  altrouting  must  be  attempted.  The  following 
trunks  are  now  out  of  service: 


34JMB1 

Hillingdon-  -  Langer  kopf 

34JMB2 

Hillingdon-  -  Langerkopf 

34JMC1 

Hillingdon-  -  Schoenfeld 

34JMC2 

Hillingdon-  -  Schoenfeld 

34JMA1 

Hillingdon-  -Feldberg 

34JMA2 

Hillingdon-  -  Feldberg 

34JMA3 

Hillingdon-  -  Feldberg 

34JMA4 

H illingdon-  -  Feldberg 

34CZA1 

Hillingdon-  -  Vaih  ingen 

The  altroute  search  begins  at  the  trunk  level.  The  starting  station  for  the 
search  is  Hillingdon  because  the  path  from  Hillingdon  to  Swingate  is  identified 
as  a  dead  end  spur  by  the  goal  station  definition  routine  (Report  3,  Section 
2.6.5).  Likewise,  the  terminal  station  for  the  trunk  searches  is  either 
Schoenfeld  or  Feldberg  due  to  the  dead  end  spur  from  Schoenfeld  to  Houtem. 
The  search  for  preemptable  groups  to  altroute  the  trunks  fails  in  all  cases 
at  Martlesham  Heath  due  to  the  absense  of  any  spare  groups  or  preemptable 
trunks.  The  trunks  are  decomposed  into  their  circuits  for  circuit  altrouting 
in  groups  with  common  altroute  ends. 
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The  circuits  in  the  altroute  group  between  Hillingdon  and  Langerkopf  are 
identified  in  Table  A-l.  All  circuits  listed  are  voice  circuits  and  also  are 
full  duplex.  Altrouting  this  group  of  circuits  is  representative  of  circuit 
altrouting  in  the  European  theatre.  The  steps  at  each  search  station  will 
be  detailed  in  terms  of  disc  accesses  needed  to  read  data,  stations  accessible, 
trunks  used,  preemptions  made,  and  costs  to  the  new  stations.  The  actual 
CCSD  matching  of  a  particular  preemptable  circuit  with  an  altroute  group 
circuit  is  not  given  because  it  is  not  important  to  the  understanding  of  the 
process.  The  matching  of  the  circuits  by  RPs  is  given  instead  in  order  to 
demonstrate  the  preemption  rule  for  circuit  selection.  The  first  step  in  the 
altroute  search  process  is  explained  in  great  detail  in  order  to  make  the 
process  clear.  The  remaining  steps  are  given  in  terms  of  brief  summaries 
of  the  important  search  parameters  at  each  station. 

Altrouting  the  Hillingdon- -Langerkopf  Circuit  Group 

Step  1 — The  first  search  station  is  Hillingdon.  It  is  labelled  as  CLOSED  in 
its  TREE  file  entry  (recall  that  file  TREE  was  defined  in  Report  3, 

Section  2.6.3,  to  store  the  station  labels  during  the  search).  The  reading 
of  the  station  file  for  Hillingdon  (HIN)  identifies  three  links  from  it:  M0281  to 
Botley  Farm,  M0095  to  Bovington,  and  M0054  to  High  Wycombe.  The  link 
M0281  is  temporarily  set  to  failed  in  order  to  identify  the  dead  end  spur 
created  by  the  M0092  link  failure.  It  is  useless  to  consider  its  trunks 
because  they  lead  to  a  dead  end  where  altrouting  is  concerned. 

Step  la- -This  step  examines  routes  over  M0095  from  Hillingdon.  The  link 
file  record  for  M0095  is  read  in  order  to  find  the  stations  accessible  from 
Hillington  and  which  trunks  make  that  access.  Six  trunks  are  found  which 
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TABLE  A-l.  HILLINGDON- LANGERKOPF  CIRCUIT  GROUP 


Circuit 

RP 

FS 

ITS 

9  A  DA 

1C 

Hillingdon 

Langerkopf 

9ADN 

1C 

Hillingdon 

Langerkopf 

6E19 

1C 

Hillingdon 

Langerkopf 

6F86 

1C 

Hillingdon 

Langerkopf 

9HED 

ID 

Hillingdon 

Langerkopf 

DN50 

ID 

Hillingdon 

Langerkopf 

9HMS 

ID 

Hillingdon 

Langerkopf 

6F14 

ID 

Hillingdon 

Langerkopf 

6F15 

ID 

Hillingdon 

Langerkopf 

9ADB 

1G 

Hillingdon 

Langerkopf 

9  A  DC 

1G 

Hillingdon 

Langerkopf 

9GTN 

1G 

Hillingdon 

Langerkopf 

9ADP 

1G 

Hillingdon 

Langerkopf 

9ADG 

1G 

Hillingdon 

Langerkopf 

9  A  DR 

1G 

Hillingdon 

Langerkopf 

9  ADS 

1G 

Hillingdon 

Langerkopf 

9ADT 

1G 

Hillingdon 

Langerkopf 

9HDM 

1G 

Hillingdon 

Langerkopf 

6E47 

1G 

Hillingdon 

Langerkopf 

9DQY 

1G 

Hillingdon 

Langerkopf 

W106 

2C 

Hillingdon 

Langerkopf 

WA8Z 

2C 

Hillingdon 

Langerkopf 

WEF9  (a)* 

2E 

Hillingdon 

Langerkopf 

WEF9  (b)* 

2E 

Hillingdon 

Langerkopf 

C606 

2F 

Hillingdon 

Langerkopf 

9HCC 

21 

Hillingdon 

Langerkopf 

WB5C 

3A 

Hillingdon 

Langerkopf 

C674 

3A 

Hillingdon 

Langerkopf 

Two  different  segments  of  a  multi- point  circuit. 


access  Martlesham  Heath  (MAM)  from  Hillingdon  over  link  M0092.  Two 
trunks  access  Crou^iton  but  neither  is  listed  in  the  data  base  so  this  station 
access  is  not  considered  further.  Station  MAM  is  entered  into  TREE  and 
labelled  as  OPEN. 

Selection  of  preemptable  circuits  can  begin  once  the  six  trunk  files  of  the 
trunks  from  Hillingdon  to  Martlesham  Heath  are  read.  Table  A-2  identifies 
the  circuits  preempted  on  those  six  trunks.  The  selection  begins  by  pre¬ 
empting  the  lowest  RP  circuit  on  the  six  trunks  by  the  highest  RP  circuit  in 
the  altroute  group.  The  second  lowest  RP  circuit  on  the  six  trunks  is 
preempted  by  the  second  highest  RP  circuit  in  the  altroute  group  and  so  on. 
The  process  ends  when  either  all  altroute  group  circuits  are  matched  with 
a  preemptable  circuit  or  no  preemption  of  a  lower  RP  circuit  can  be  made. 
The  last  circuit  preempted  and  its  matching  altroute  circuit  will  be  nearly 
the  same  RP  level  if  preemption  ends  prematurely. 

The  trunk  columns  in  Table  A -2  define  the  altroute  group  circuits  which 
preempted  a  trunk's  circuits  at  the  RP  listed  in  the  left-hand  RP  column. 

Most  circuits  were  altrouted  by  using  00  or  spares,  and  only  three  circuits 
required  higher  RP  preemptions.  The  entire  altroute  group  could  not  be 
altrouted  over  this  set  of  trunks  to  MAM  because  of  a  lack  of  low  RP  circuits. 
The  next  circuit  needing  a  preemption  is  at  the  2E  level,  and  there  are  no 
preemptable  circuits  lower  in  RP  than  2 E  on  any  of  the  trunks.  The  numbers 
in  the  parentheses  indicate  the  totals  of  each  RP  level  in  the  altroute  group 
which  were  found  to  be  altrouted  to  MAM  over  M0095. 

To  further  explain  the  preemption  situation.  Figure  A -3  shows  the  preempting 
in  terms  of  a  group  capacity  distribution  as  was  used  in  Report  3  (Section  2.9) 
to  explain  the  altroute  probability  analysis. 
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TABLE  A-2.  PREEMPTION  SELECTIONS  FOR  STEP  1  a 


U  Q 

* 

H  H 

w 

w 

+  + 

N 

CM 

co 

u 

u 

CM 

CM 

O  U  H-  < 

eg  m  n  en 


4> 

U 

• v  a 
oca 

o  rt  03 


Number  of  circuits  in  the  altroute  group  for  which  preemptions  were  found. 


The  curve  labelled  "Preemptable  Group  Capacity"  is  the  number  of  circuits 
on  the  six  trunks  that  lie  below  the  listed  RP  level.  The  "Altroute  Group 
Capacity"  curve  shows  the  number  of  circuits  in  the  altroute  group  that  are 
above  the  listed  RP.  The  intersection  of  the  curves  gives  the  RP  level  for 
the  lowest  RP  circuit  altrouted  over  the  six  trunks.  The  same  result  present¬ 
ed  in  Table  A-2  is  given  by  this  plot. 

The  next  step  in  creating  the  label  for  MAM  (of  the  altroute  segment  from 
HIN)  is  to  calculate  the  costs.  As  explained  in  Report  3  (Section  2.6.3), 
the  cost  of  an  altroute  segment  is  taken  to  be  the  route  cost  for  the  highest 
RP  circuit  in  the  altroute  group.  In  this  example,  we  have  four  RP  1C 
circuits  which  tie  for  the  highest  RP  circuit.  The  costing  will  in  this  case 
be  the  average  over  all  four  1C  circuits. 

The  cost  of  the  route  to  MAM  from  HIN  is  found  for  all  four  RP  1C  circuits. 
All  four  have  reached  MAM  by  preempting  RP  00  circuits  so  that  there  is  no 
preemption  cost  contribution  (the  cost  from  Figure  A-2  is  zero).  The  highest 
RP  circuits  are  paired  with  the  lowest  RP  preemptable  circuits  even  though 
they  could  preempt  higher  RP  circuits  on  the  six  trunks.  This  makes  the 
route  cost  reflect  the  cost  that  would  exist  if  each  high  RP  circuit  were 
altrouted  by  itself.  The  lower  RP  circuits  in  the  altroute  group  are  just 
being  carried  along  in  this  altroute  search  as  a  bonus.  They  do  not  theoreti¬ 
cally  rate  consideration  until  the  highest  RP  circuits  have  been  altrouted. 

The  route  cost  will  now  be  found  from  the  patching  and  mileage  costs.  The 
path  between  HIN  and  MAM  has  five  links  whose  mileages  add  to  102  miles. 
When  a  patching  cost  for  one  station  is  added,  the  cost  sum  is  152.  This  is 
the  known  cost  of  the  four  1C  circuits'  altroutes  from  HIN  to  MAM. 


The  last  item  required  for  the  MAM  label  is  an  estimate  of  the  mileage  to 
the  goal  station  of  Langerkopf  (LKF).  This  estimate  is  made  by  examining 
pairs  of  paths  that  MAM  and  LKF  are  on.  We  determine  which  path  pair 
has  the  shortest  path  mileage  plus  euclidean  path  end  distance  from  MAM  to 
LKF  (see  Report  3,  Section  2.6.4  for  details  of  this  process).  This 
particular  pair  of  stations  is  estimated  to  be  416  miles  apart  using  the  fact 
that  the  MAM  to  Feldberg  (FEL)  path  and  FEL  to  LKF  path  intersect  at  FEL. 
This  cost  is  added  to  the  known  altroute  cost  to  yield  an  estimated  total 
altroute  cost  of  568.  This  number  will  be  compared  to  other  labelled  OPEN 
stations  in  the  TREE  file  in  order  to  determine  which  partial  altroute  is 
most  promising  for  further  expansion. 

A  summary  of  the  altroute  segments  over  link  M0095  is  given  below.  This 
type  of  summary  will  be  used  for  the  remainder  of  the  search  steps.  This 
first  step  was  presented  in  detail  only  to  clarify  the  process  used  in  the 
altrouting  algorithm. 

Search  station:  HIN  (now  labelled  as  CLOSED).  Files  records  read:  1  link, 
7  trunks. 


Known 

Estimated 

Accessible* 

Trunks 

Highest  RP 

Circuits 

Segment 

Total 

Stations 

Used 

Preempted 

Altrouted 

Cost 

Cost 

MAM 

33JMA1 

00 

24; 

152 

568 

33JMA2 

00 

4,  1C 

5,  ID 

33JMA3 

11.  1G 

2,  2C 

33JMA4 

3A 

2,  2E 

33JMA5 

2F 

33JM15 

00 

*These  stations  are  given  search  status  OPEN. 
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Step  lb- -The  other  link  out  of  Hillingdon  is  M0054.  This  link  allows  access 
to  the  satellite  link  at  Croughton.  Unfortunately,  the  circuits  or  the  satellite 
link  are  all  RP  1C  and  thus,  circuits  cannot  be  preempted  further  than 
Croughton  in  this  direction  and  allow  expansion  of  the  altroute. 

Table  A-3  summarizes  all  of  the  altroute  segments  generated  from  Hilling¬ 
don.  The  data  listed  in  Table  A-3  represents  all  OPEN  search  stations' 
labels  at  this  point. 

Step  2 --The  lowest  cost  OPEN  station  listed  in  the  HIN  CLOSED  station 
label  summary  (see  Table  A-3)  is  Croughton.  As  mentioned  earlier,  no 
stations  are  accessible  from  Croughton  due  to  the  lack  of  preemptable 
circuits.  Croughton  is  labelled  as  CLOSED  but  no  new  OPEN  stations  are 
generated. 

Step  3- -The  only  other  OPEN  station  to  examine  (and  thus  the  lowest  cost 
OPEN  station)  is  MAM.  The  only  link  to  examine  is  T0110  to  Hoek  Van 
Holland.  The  link  entering  MAM  is  not  examined  because  we  have  not 
jumped  over  the  goal  station  in  reaching  MAM.  The  link  used  to  enter  a 
station  will  be  considered  only  when  "back-hauling"  is  required.  There  are 
three  backbone  stations  accessible  from  MAM  over  this  link:  Muhl  (MUL), 
Feldberg  (FEL),  and  Donnersberg  (DON).  Remember  only  backbone  stations 
are  worth  considering  in  an  altroute;  all  other  stations  are  on  spurs  which 
lead  to  dead  ends  in  terms  of  altrouting.  The  label  summary  for  these 
stations  is  given  in  Table  A-4.  Notice  that  this  step  limits  the  altroute  group 
to  fewer  circuits  than  could  be  altrouted  to  MAM  from  HIN.  These  three 
stations  compose  the  entire  OPEN  station  list  at  this  point  in  the  search. 


191 


TABLE  A-3.  LABEL  SUMMARY  FOR  STEP  1 
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TABLE  A-4.  LABEL  SUMMARY  FOR  STEP  3 


Search  station:  MAM.  File  records  read:  1  station.  1  link,  6  trunk. 


Known 

Estimated 

Accessible 

Trunks 

Highest  RP 

Circuits 

Segment 

Total  Altroute 

Stations 

Used 

Preempted 

Altrouted 

Cost 

Cost 

MUL 

34JZH1 

2C 

9: 

4,  1C 

5,  ID 

645 

741 

FEL 

34JZA6 

00 

24: 

548 

618 

34JZB1 

3A 

4,  1C 

5,  ID 

34JZB2 

00 

11,  1G 

34JZB3 

3A 

2,  2C 

2,  2E 

DON 

34CZB1 

00 

9: 

4,  1C 

5,  ID 

650 

682 

Step  4 — Feldberg  is  selected  as  the  lowest  cost  OPEN  station.  The  number 
of  links  with  which  it  can  generate  altroutes  is  six  (exclude  the  M0291  link 
because  it  was  used  to  enter  FEL).  The  stations  accessible  from  Feldberg 
are: 


Langerkopf  (LKF) 
Bann  (BAN) 
Donnersberg  (DON) 
Frankfurt  (FKT) 
Schoenfeld  (SCH) 
Hiedelberg  (HDG) 
Lindsey  (LSY) 


M0063 

M0063-M0331 

M0298-M0372 

M0070 

M0891-M0890 

M0298-M0372-M0305 

D0123 
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Table  A- 5  summarizes  the  labelling  of  these  stations  from  Feldberg. 

Notice  that  the  goal  station  (Langerkopf)  is  labelled  in  this  step.  The  search 
does  not  terminate,  however,  until  Langerkopf  is  selected  as  the  lowest 
cost  OPEN  station.  Donnersberg  is  reached  again  by  this  step,  but  the 
cost  of  the  route  from  Feldberg  is  higher  than  the  cost  from  Martlesham 
Heath  due  to  an  additional  patch  at  Feldberg.  The  label  for  Donnersberg 
from  MAM  is  kept.  The  label  from  FEL  is  ignored. 

Step  5 — The  group  of  OPEN  stations  are  all  stations  in  Table  A-4  and  Muhl 
and  Donnersberg  in  Table  A-3.  The  lowest  cost  station  is  Langerkopf  at 
598.  Since  it  is  the  goal  of  the  search,  the  search  will  end  here.  The 
altroute  is  then  defined  by  the  parent  station  back- pointers: 

Hillingdon— Martlesham  Heath  M0095-M0096-M0365-M0098 
Martlesham  Heath- -Feldberg  T0110-T0111-D0112-M0291 
Feldberg — Langerkopf  M0063 

Circuits  altrouted;  Four—lC/5,  ID/11,  1G/1,  2C 
A.  3  EXAMPLE  2 

The  link  from  Feldberg  to  Langerkopf  fails  (M0063).  This  altrouting 
scenario  is  the  one  used  in  Report  3  (Section  2.8)  to  examine  response  times 
in  altrouting.  It  will  be  used  here  as  an  example  of  trunk  altrouting.  The 
trunks  out  of  service  due  to  the  link  failure  are: 

44JMQ1  Langerkopf- -Feldberg 

44JMQ2  Langerkopf- -Feldberg 
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TABLE  A- 5.  LABEL  SUMMARY  FOR  STEP  4 


Search  station:  FEL.  File  records  read:  1  station,  6  link,  35  trunk. 


Accessible 

Stations 

Trunks 

Used 

Highest  RP 
Preempted 

Circuits 

Altrouted 

— 

Known 

Segment 

Altroute 

Cost 

Estimated 
Total  Altroute 
Cost 

LKF 

44JMQ1 

2E 

21: 

598 

598 

44JMQ2 

4,  1C 

44JMQ3 

5,  ID 

44JMQ4 

11,  1G 

44JMQ5 

2E 

1,  2C 

44JMQ6 

-- 

44JMQ7 

2E 

BAN 

44JMX7 

2C 

10; 

680 

692 

4,  1C 

5,  ID 

1,  1G 

DON 

44XMD1 

2E 

18: 

652 

684+ 

44CMD2 

-- 

4,  1C 

44CMD3 

3A 

5.  ID 

44CMD4 

00 

9,  1G 

44CMD5 

-- 

44CMD6 

3A 

44CMD8 

-- 

>{c 

Goal  station  LKF  has  been  labelled. 

+This  label  cost  higher  than  previous  label  in  Table  A-3.  Ignore  this  DON  label 
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TABLE  A- 5.  LABEL  SUMMARY  FOR  STEP  4  (concluded) 


Search  station:  FEL.  File  records  read:  1  station,  6  link,  35  trunk. 


Accessible 

Stations 

Trunks 

Used 

Highest  F  P 
Preempted 

Circuits 

Altrouted 

Known 

Segment 

Altroute 

Cost 

Estimated 
Total  Altroute 
Cost 

FKT 

44CMN1 

00 

24: 

609 

690 

44CMN2 

-- 

4.  1C 

44CMN3 

-- 

5,  ID 

44CMN4 

00 

11,  1G 

44CMN5 

00 

2,  2C 

44CMN6 

-- 

2,  2E 

44CMN7 

-- 

44CMN8 

-- 

SCH 

44JMX1 

-- 

9: 

695 

791 

44JMX2 

-- 

4,  1C 

44JMX3 

00 

5,  ID 

44JMX4 

-- 

HDG 

44CMH1 

2C 

9; 

688 

756 

4,  1C 

5,  ID 

LSY 

44JMP1 

00 

24: 

614 

676 

44JMP2 

-- 

4,  1C 

44JMP4 

00 

5,  ID 

44JMP5 

00 

11.  1G 

44JMP6 

-- 

2,  2C 

44JMP8 

-- 

2,  2K 

44JMP9 

-- 
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44JMQ3 

La  nger  kopf-  -  F  eldb  er  g 

44JMQ4 

Langerkopf — Feldberg 

44JMQ5 

Langer  kopf-  -  Feldberg 

44JMQ6 

Langerkopf- -Feldberg 

44JMQ7 

Langerkopf — Feldberg 

44JMX7 

Bann- -Feldberg 

34CZB1 

Donnersberg--Martlesham  Heath 

34JZF1 

Langerkopf- -Martlesham  Heath 

The  entry  point  is  again  the  trunk  level  altrouting  routine.  This  time, 
however,  we  will  find  a  trunk  altroute.  The  trunks  are  selected  by  impor¬ 
tance  for  altrouting  in  the  order  of  the  sum  of  their  circuits'  RPs.  This 
ensures  that  the  largest  number  of  important  circuits  are  handled  rapidly. 

In  this  group  of  trunks,  44JMQ5  is  the  most  important  trunk.  Its  highest 
carried  RP  is  1A,  and  its  lowest  RP  circuit  is  00.  Since  it  has  a  00RP 
circuit,  the  altroute  of  this  trunk  can  only  use  spare  groups.  It  can  never 
preempt  an  entire  trunk  due  to  the  circuit  preemption  rule  acting  on  the 
RP  00  circuits. 

Altrouting  Trunk  44JMQ5 

Step  1--The  search  for  an  altroute  for  this  trunk  begins  at  Langerkopf  (LKF) 
and  seeks  a  goal  station  of  Feldberg  (FEL).  The  altroute  path  "costs"  will 
be  calculated  as  the  circuit  costs  were  in  Example  1.  The  only  difference 
is  in  the  preemption  cost  which  is  now  taken  as  the  sum  of  all  of  the  pre¬ 
empted  trunk's  RPs.  This  cost  will  be  much  larger  in  the  sum  cost  due  to 
12  circuits*  RPs  being  added  into  the  sum.  For  this  reason,  the  scale 
factor  of  this  component  of  total  cost  will  be  reduced  by  12.  This  renews 
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the  cost  component  equivalencies  derived  in  Example  1.  In  effect,  we  are 
setting  an  average  preempted  circuit  RP  of  2 A  on  a  preempted  trunk 
equivalent  to  two  patches  or  100  miles  of  route  mileage. 

The  links  from  Langerkopf  over  which  the  altroute  search  is  made  are: 


Link 

Langerkopf  to: 

M0331 

Bann 

MO  3  78 

Pirmasens 

M0068 

Muhl 

M0671 

Donnersberg 

M0373 

Friolzheim 

The  link  to  Feldberg  is  not  considered  because  it  is  the  failed  link.  The 
only  link  over  which  this  altroute  cannot  access  a  new  station  is  M0671; 
there  are  no  spare  groups.  The  stations  accessible  over  the  remaining 
links  at  the  group  or  circuit  level  are  labelled  and  listed  in  Table  A-6. 


Step  2 — The  station  at  Donnersberg  is  the  lowest  cost  OPEN  station  at  this 
step  and  will  be  examined  for  altroute  expansion  next.  The  links  out  of 
Donnersberg  are: 


Link 

Donnersberg 

M0364 

Lindsey 

MO  3  72 

Rhein  Main 

M0305 

Heidelberg 

MO  72  4 

Pirmasens 
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TABLE  A-6.  LABEL  SUMMARY  FOR  STEP  1 


Search  station:  Langerkopf.  File  records  read:  1  station,  6  link. 


Accessible 

Stations 

Link  and  Group 
or  Trunk 
Used 

Highest  RP 
Preempted 

Known 

Segment 

Cost 

Estimated 
Total  Altroute 
Cost 

Bann 

M0331 

2/5* 

Spare 

62 

144 

Schoenfeld 

M0068 

2/4 

Spare 

146 

234 

Donnersberg 

M0378 

3/2 

Spare 

93 

139 

Stuttgart 

M0373 

4/1 

Spare 

123 

220 

Supergroup /group  used. 

T0328  Hohenstadt 

MO  671  Langerkopf 

M0308  Koenigstuhl 

The  link  to  Langerkopf  is  ignored  because  any  labelling  of  it  will  exceed 
the  current  labelled  cost:  zero  (it  is  the  starting  station).  The  link  to 
Pirmasens  is  the  link  used  to  enter  Donnersberg  and  need  not  be  examined 
for  a  "back-haul"  because  the  goal  station  has  not  been  jumped  over  in  the 
path  to  Donnersberg.  The  labelled  stations  over  the  remaining  links  are 
given  in  Table  A- 7. 

Step  3--The  OPEN  stations  at  this  step  are:  Schoenfeld,  Stuttgart,  Feldberg, 
Koenigstuhl  and  Lindsey.  Lindsey  is  the  lowest  estimated  path  cost  of  any. 

It  will  be  labelled  CLOSED  and  examined  next.  The  only  station  accessible 
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TABLE  A- 7.  LABEL  SUMMARY  FOR  STEP  2 
Search  station:  Donnersberg.  File  records  read:  1  station,  6  link. 


Accessible 

Stations 

Link  and  Group 
’''or  Trunk 
Used 

Highest  RP 
Preempted 

Known 

Segment 

Cost 

Estim. 
Total  Alt 
Cost 

Feldberg 

M0372 

5/3 

Spare 

197 

197 

Koenigs  tuhl 

M0308 

3/5 

Spare 

183 

240 

Lindsey 

M0364 

1/1 

Spare 

173 

189 

over  its  only  link  is  Feldberg  (D0123,  2/5).  The  cost  of  the  label  to 
Feldberg  from  Lindsey  is  239.  This  cost  exceeds  the  previously  established 
label  from  Donnersberg  so  it  is  not  considered  further. 

Step  4- -The  lowest  cost  OPEN  station  is  now  Feldberg,  the  goal  station. 

The  search  ends  at  this  step  with  the  altroute  established: 


Langerkopf-  -Donnersberg 
Donnersberg-  -Feldberg 


M0378  3/2 

M0372  5/2 

M0298 


Cost  «  197 


A. 4  ALGORITHM  EXECUTION  TIME 


The  final  analysis  of  this  section  will  be  to  estimate  the  computer  execu¬ 
tion  time  required  in  order  to  do  the  two  examples  presented  here.  Esti¬ 
mation  of  this  time  will  be  made  using  the  software  sizing  estimates  for 
functional  program  sections  (See  section  4.4. 1.2  of  this  report).  The  time 
for  the  computer  execution  will  include  the  time  required  to  complete  the 
HOL  instructions  specified  in  the  software  sizing  plus  the  time  required 
to  access  the  disc  during  record  retrieval.  Typical  time  for  disc  access 
will  be  taken  as  50  milliseconds.  The  HOL  instructions  will  be  assumed 
to  be  composed  of  an  average  of  five  assembly  level  instructions.  The 
average  assembly  level  execution  time  for  a  variety  of  computers  the  size 
of  the  ACOC  machine  is  about  five  microseconds.  This  makes  the  HOL 
execution  time  approximately  2  5  microseconds. 

The  estimation  of  the  disc  accesses,  HOL  instructions,  and  computer 
execution  times  needed  for  each  step  in  the  two  examples  are  given  in 
Tables  A-8  and  A-9.  These  results  show  a  rather  small  execution  time 
for  each  example  in  comparison  with  other  activities  occuring  during 
altroute  implementation  (see  Report  3,  Section  2.8).  This  result  for  these 
two  typical  altrouting  examples  demonstrates  the  feasibility  of  real-time 
altroute  search  algorithms  as  a  part  of  altroute  control. 
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TABLE  A- 8.  EXECUTION  TIME  FOR  EXAMPLE  1 


Step 

Number  of  ^ 
Disc  Reads 

Number  of 
HOLs 

Execution 
Time  (Secs) 

Job  queue  set-up 

22 

5420 

1.24 

Step  la 

8 

1580 

0.44 

Step  lb 

7 

1370 

0.38 

Step  2 

3 

310 

0. 16 

Step  3 

8 

2755 

0.47 

Step  4 

42 

8660 

2.32 

Step  5 

-- 

15 

0.00 

Put  altroute 
and  preemptions 
into  data  base 

84 

4100 

4.30 

Totals 

174 

24,210 

9.31 

*Does  not  include  possible  fault  files  needed  to  identify 
failed  segments. 
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TABLE  A- 9.  EXECUTION  TIME  FOR  EXAMPLE  2 


Step 

Number  of 
Disc  Reads 

Number  of 
HOLs 

Execution 
Time  (Secs) 

Job  queue 
set-up 

11 

2400 

0.61 

Step  1 

7 

2225 

0.41 

Step  2 

7 

1755 

0.39 

Step  3 

2 

690 

0. 12 

Step  4 

-- 

15 

Put  altroute 
and  preemptions 
into  data  base 

3 

145 

0.15 

Totals 

30 

7230 

1.68 

i 

i 

( 
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APPENDIX  B 


MANNING  BENEFITS  ANALYSIS  FOR  ALTROUTE  CONTROL 

B.  1  INTRODUCTION 

Due  to  the  automation  of  altroute  generation  and  implementation  proposed 
in  this  study,  the  manpower  allocated  at  DCS  stations  will  be  impacted.  The 
coordination  required  to  synthesize  an  altroute  among  a  number  of  stations 
will  be  eliminated  due  to  the  ACOC  altroute  synthesis  algorithms.  The 
patching  instructions  will  be  automatically  generated  and  transmitted  to 
stations  involved.  The  future  deployment  of  CRUs  will  further  reduce  man¬ 
power  by  allowing  remote,  automatic  patching  implementation  of  the 
altrouting  controls.  Finally,  the  integration  of  the  altrouting  algorithms 
with  the  ACOC  data  base  manager  will  provide  updated  route  changes  without 
reporting  via  the  station  personnel.  The  manpower  reductions  at  the  station 
level  due  to  altroute  control  will  thus  be  in  coordination,  patching  and 
reporting  functional  areas. 

B.2  AN  ANALYSIS  METHOD 

The  analysis  of  the  impact  of  altrouting  control  upon  manpower  at  the  station 
level  will  be  analyzed  with  a  queueing  model  of  controller  functions  in  the 
face  of  non- scheduled  outage- related  tasks.  The  model  used  was  developed 
in  Reference  9.  The  purpose  of  that  report  was  to  formally  define  the 
manpower  impact  analysis  tools  to  be  used  in  automation  studies  such  as 
this  one.  The  model  is  appropriate  for  this  study  with  only  a  few  modifications. 
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The  analysis  model  describes  the  station  controller's  activities  as  a  simple 
first-in,  first-out  queue.  Each  controller  is  defined  as  a  server  to  the 
queue  inputs  which  are  divided  into  three  activities  related  to  outages: 

•  Circuit  restoration  and  fault  clearing 

•  Assistance  to  other  stations 

•  Near- real- time  reporting 

The  queue  of  tasks  in  these  areas  is  set  up  to  be  infinite  in  capacity  with 
each  task  assigned  to  the  next  available  controller,  regardless  of  the  nature 
of  the  task.  The  task  arrival  time  and  task  processing  time  are  assumed 
to  have  constant  conditional  probability  density.  The  queue  is  characterized 
by  the  sum  of  the  arrival  times  and  an  average  process  time  which  reflects 
the  individual  times  for  the  three  tasks  described  above. 

The  steady-state  output  of  the  queue  and  in-process  task  load  is  used  as  the 
service  measure  of  personnel  at  a  station.  The  circuit  restoration  tasks  in 
the  queue  or  in-process  are  assumed  to  represent  out- of- service  circuits. 

A  station  availability,  defined  as  the  percent  of  circuits  at  a  station  that  are 
in  service,  is  the  measure  of  effectiveness  of  the  manning  level  at  the 
station.  Changes  in  arrival  and  process  time  due  to  altroute  control  will  be 
made  in  an  effort  to  determine  how  many  fewer  controllers  can  be  used  to 
achieve  the  same  availability  measure.  In  addition,  the  idle  time  from  these 
randomly  arriving  outage  tasks  will  be  monitored  so  that  estimated  manpower 
reductions  are  consistent  with  the  idle  time  necessary  for  scheduled  tasks. 


The  queueing  model  is  defined  by  the  following  definitions  and  equations: 

Probability  that  an  event  will  occur  in  time  dt  at  time  t 
assuming  that  it  has  not  occurred  prior  to  t  *  a  constant 
(the  "rate  constant"  of  the  process) 

:  Rate  constant  for  circuit  outage  arrivals  at  the  station 

:  Rate  constant  for  handling  circuit  outages 

X,,  :  Rate  constant  for  the  arrival  of  inter-station  assistance  requests 

dt 

H  :  Rate  constant  for  satisfying  inter- station  assistance  requests 
Xg  :  Rate  constant  for  required  near- real- time  reporting 
H  :  Rate  constant  for  handling  a  near-real- time  report 
u  :  Average  task  processing  rate  constant 
X  :  Total  task  arrival  rate  constant 
k  :  Number  of  controllers  at  a  station 

q  :  Average  steady- stage  task  load  in  the  queue  and  in-process 
q  *  B  +  Kp 

1-p 

X  =  X1+X2+X3 
X1  t  X2  t  X  3 

**7  +  *7  +  M3 
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k 


i  *  0 


(Kp)1 

i! 


(Kp)1 
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A  -  Station  measure  of  service  availability 
(No.  of  crkts.  handled  by  a  station)  - 

A  = _ _ 

(No.  of  crkts.  handled  by  a  station) 
Station  percent  idle  time  =  t  *  (1  -  p)  x  100%. 


B.3  THE  BASELINE  MANNING  ANALYSIS 


The  first  step  in  examining  benefits  of  altrouting  controls  is  to  establish 
the  baseline  manning  availability  measure  and  idle  time  percentages  for 
the  DCS  stations.  The  difference  between  this  baseline  analysis  and  the 
results  of  .utter  analyses  with  controls  considered  will  serve  to  estimate 
the  possible  manpower  reductions  and  benefits  of  altrouting  controls. 

The  source  of  the  rate  parameters  for  the  baseline  analysis  comes  from  the 
Croughton  manpower  survey  (Reference  10),  the  "O&M  Manning  Studies" 
(Reference  9),  and  the  "Digital  Network  Control  Cost  Benefits  Study" 
(Reference  11).  The  Croughton  manning  was  analyzed  and  reported  in  1974. 
The  task  arrival  and  task  process  times  of  that  study  were  analyzed  in  the 
two  reports  to  arrive  at  the  rate  constants  defined  earlier. 
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Rate  Constant 


Estimate  Value  for  Croughton 


^*1 

>2 


^2 

X3 

m3 


1. 10 /hour 
0. 43 /hour 
13. 44/hour 
5. 46 /hour 
2. 60 /hour 
13.  70 /hour 


Several  modifications  of  this  basic  data  must  be  made  before  using  it  as 
the  baseline  of  this  analysis.  First,  ATEC  is  assumed  to  be  fully  deployed 
in  the  baseline  model  of  this  study.  Reference  11  estimates  the  following 
average  changes  in  the  pre-ATEC  Croughton  rate  constants  due  to  ATEC 
deployment: 


Rate  Constant  Estimate  Post- ATEC  Value  for  Croughton 


X1 

0.  99/hour 

(-10%) 

M1 

0. 47/hour 

(+10%) 

*2 

13. 44 /hour 

no  change 

^2 

7.  64 /hour 

(440%) 

X3 

2 . 6  /hour 

no  change 

^3 

21. 9 /hour 

(+60%) 

The  reductions  in  the  task  rates  will  be  briefly  explained  here.  The 
reduction  in  processing  time  for  the  circuit  outages  is  primarily  a  result 
of  ATEC  fault  isolation  algorithms.  The  circuit  outage  arrival  reduction  is 
attributed  to  the  ATEC  performance  reporting  function  which  would  pick  up 
radio  degradations  before  they  could  become  serious  enough  to  impact 
service. 
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The  impact  of  ATE C  upon  inter- station  assistance  times  would  be  to 
automate  testing  which  accounts  for  40%  of  the  activity  for  which  stations 
require  interaction.  Finally,  the  reduction  in  reporting  times  is  an  estimate 
first  made  in  the  "O&M  Manning  Studies"  report  and  is  justified  by  the  fact 
that  ATEC  will  provide  automatic  report  transmission  and  report  format 
prompting  in  report  preparation. 

This  analysis  will  diverge  from  the  previous  work  in  the  estimate  of  the 
circuit  outage  restoration  rate  parameter.  The  sources  of  this  parameter 
point  out  that  this  rather  long  time  per  circuit  outage  is  not  due  to  the 
volume  of  work  the  controller  must  do  but  to  the  long  time  between  commence¬ 
ment  of  action  and  final  resolution.  In  fact,  the  time  spent  per  circuit  outage 
at  the  Crou^iton  station  was  estimated  at  8.  5  minutes  for  a  circuit  not 
requiring  altrouting  and  20  minutes  for  a  circuit  requiring  altr outing  action 
at  the  station.  The  extra  time  per  outage  in  this  queueing  model  assumes 
that  the  controller  is  idle  for  two  hours.  This  assumption  is  certainly  not 
true;  the  controller  is  no  doubt  working  on  other  tasks  during  this  time 
between  outage-related  activities.  To  model  this  situation  more  clearly, 
either  the  controller  should  be  considered  a  multi-server  or  the  actual  task 
process  time  should  be  used  for  the  rate  constant  in  this  queueing  model. 

The  latter  approach  is  selected  here.  The  circuit  outage  rate  constant  for 
Croughton  will  be  set  at  5.  3 /hour  to  reflect  the  fact  that  25%  of  the  circuits 
will  require  the  20-minute  altrouting  process  time,  and  the  other  75%  will 
use  only  8.  5  minutes  of  the  controller's  time.  The  adjustment  of  this  pre- 
ATEC  data  for  the  baseline  model  of  this  analysis  will  reduce  the  response 
time  for  fault  isolation  to  one  minute  due  to  ATEC  fault  isolation  automation. 
The  post-ATEC  circuit  outage  rate  constant  for  this  baseline  analysis  is 
then  8. 9 /hour. 


210 


The  next  adjustment  of  the  Croughton  rate  constants  is  to  scale  them  for  the 
size  of  each  station's  circuit  load.  The  arrival  rates  of  each  message  type 
will  be  scaled  from  the  Croughton  data  using  the  relative  number  of  circuits 
at  a  station  compared  to  Croughton.  This  should  adequately  represent  the 
task  load  variations.  The  process  times  will  be  left  unchanged  under  the 
assumption  that  the  quality  of  controllers  at  all  sites  is  uniform.  Table  B-l 
summarizes  the  scaling  of  task  arrival  times  for  the  stations  in  the  European 
DCS  of  this  study.  The  manpower  assigned  to  each  station  is  also  given  and 
represents  the  personnel  specified  as  technical  controllers  (Reference  11). 

The  result  of  this  baseline  analysis  is  presented  in  Table  B-2.  This  table 
presents  the  service  availability  measure  and  idle  time  for  the  baseline 
manning  levels.  This  data  will  be  used  later  in  comparison  with  the  altroute 
control  manning  in  order  to  determine  benefits  from  those  controls. 

B.  3  MANNING  BENEFITS  DUE  TO  CENTRALIZED  ALTROUTE  CONTROL 

The  main  automation  providing  a  manpower  impact  upon  the  stations  is  the 
centralization  of  altroute  synthesis  at  ACOC  rather  than  its  current 
decentralized  station  level  operation.  The  effect  of  this  control  is  to  reduce 
the  circuit  outage  task  process  times  at  the  stations.  The  controllers  now 
receive  their  altroute  patching  messages  from  ACOC.  The  altroute  is 
completely  defined.  No  inter- station  coordination  is  required  to  find  an 
altroute.  The  station  controller  will  review  the  plan  as  it  refers  to  his 
site  and  indicate  to  ACOC  whether  it  seems  possible.  The  concurrence  of 
all  involved  stations  then  permits  controller  patching  of  the  altroute  per  the 
ACOC  route.  No  reporting  of  the  route  upward  is  needed. 


TABLE  B-l.  SCALED  TASK  ARRIVAL  RATE  CONSTANTS 


Station 

Number  of 
Controllers 

Scale 

Factor 

Bann 

12 

1.4 

Berlin 

9 

.  63 

Croughton 

12 

1.0 

Donnersberg 

10 

4.3 

Feldberg 

16 

4.2 

Heidelberg 

10 

.  58 

Hillingdon 

20 

2.4 

Kaiserlautern 

10 

.74 

Koenigs  tuhl 

5 

2.4 

Lands  tuhl 

7 

.26 

Langerkopf 

26 

3.1 

Martlesham  Heath 

18 

1.7 

Mildenhall 

4 

.63 

Muhl 

7 

1.3 

Pirmasens 

20 

1.4 

Ramstein 

17 

1.1 

Rhein  Mein 

6 

.32 

Schoenfeld 

6 

1.5 

Sembach 

16 

.  53 

Stuttgart 

4 

1.7 

Total 

235 

Arrival  Rates 


1.56  18.8 

.69  9.3 


1.1 

4.7 

4.6 
.64 

2.6 

.8 


1.4 

1.4 
1.2 
.35 
1.7 
.  58 


13.4  2.6 

57.6  11.2 

56.5  10.9 


7.8 

32.3 

10.0 


2.6  32.3 

.29 


L . 9  22.9 
.69  9.3 


17.5 

17.5 

14.8 

4.3 

20.0 

7.1 


1.9  22.8 


1.5 

6.2 

1.9 

6.2 

.68 

8.1 

4.4 

1.8 

3.4 

3.4 

2.9 
.83 

3.9 

1.4 

4.4 
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TABLE  B-2.  BASELINE  MANNING  ANALYSIS  SUMMARY 


Station 

Baseline 

Manning 

Station 

Availability 

Percent 

Idle  Time 

Bann 

12 

.999493 

77. 

Berlin 

9 

. 999493 

86. 

Croughton 

12 

. 999493 

83. 

Donnersberg 

10 

. 999307 

15. 

Feldberg 

16 

.999461 

48. 

Heidelberg 

10 

( 

. 999493 

88. 

Hillingdon 

20 

.999453 

76. 

Kaiserlautern 

10 

. 999493 

85. 

Koenigstuhl 

5 

.997617 

5. 

Lands tuhl 

7 

.999493 

93. 

Langerkopf 

26 

. 999313 

76. 

Martlesham  Heath 

18 

.999493 

81. 

Mildenhall 

4 

.999485 

69. 

Muhl 

7 

. 999491 

63. 

Pirmasens 

20 

.999493 

86. 

Ramstein 

17 

.999493 

87. 

Rhein  Main 

6 

.999493 

89. 

Schoenfeld 

6 

.999477 

50. 

Sembach 

16 

. 999493 

93. 

Stuttgart 

4 

.998496 

16. 

Total 

235 
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The  major  reflection  of  this  task  reduction  in  the  rate  of  circuit  outage 
processing  is  to  eliminate  the  coordination  time  from  the  Croughton  response 
time  (4.  5  minutes  for  circuits  requiring  altrouting).  The  reporting  time  of 
4. 12  minutes  for  each  altroute  is  reduced  to  1  minute  per  the  analysis  in 
Report  3  (Section  2.8).  This  increases  the  Croughton  rate  constant  for 
circuit  outage  processing  to  12.4/hour  (+39%).  The  percentage  increase  in 
this  rate  constant  is  applied  to  all  of  the  individual  stations  in  calculating 
the  new  manning  due  to  altroute  control. 

The  results  of  the  manpower  analysis  for  the  case  of  altroute  control  is 
given  in  Table  B-3.  The  queueing  analysis  was  run  at  each  station  for  all 
levels  of  manning  up  to  the  baseline  level.  The  new  manpower  was  arrived 
at  by  selecting  a  manning  level  yielding  the  same  or  better  station  availability 
with  no  more  than  a  5%  reduction  in  idle  time.  The  manpower  savings  per 
station  are  tabulated  and  summed  over  the  entire  European  area.  The 
estimated  cost  savings  due  to  this  reduction  in  manning  is  estimated  at 
$0.  802  million  per  year  (using  $20,  563  per  man  year  as  a  cost  of  manning. 
Reference  11). 
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TABLE  B-3.  MANPOWER  ANALYSIS  WITH  ALTROUTE  CONTROLS 


Station 

Manning  W  ith 
Altroute  Control 

Manning 

Reduction 

Station 

Availability 

Percent 
Idle  Time 

Bann 

10 

2 

.999501 

73 

Berlin 

7 

2 

.999501 

82 

Croughton 

10 

2 

. 999501 

80 

Donnersberg 

10 

0 

.999345 

16 

Feldberg 

16 

0 

. 999470 

49 

Heidelberg 

8 

2 

. 999501 

86 

Hillingdon 

17 

3 

.999579 

72 

Kaiserlautern 

8 

2 

.999541 

82 

Koenigstuhl 

5 

0 

.998154 

6 

Lands tuhl 

5 

2 

.999501 

90 

Langerkopf 

22 

4 

.999471 

72 

Martlesham  Heath 

15 

3 

.999501 

78 

Mildenhall 

4 

0 

.999494 

69 

Muhl 

7 

0 

.  999499 

64 

Pirmasens 

15 

5 

.999501 

82 

Ramstein 

13 

4 

.999501 

83 

Rhein  Main 

5 

1 

. 999501 

88 

Schoenfeld 

6 

0 

.999486 

51 

Sembach 

9 

7 

.999501 

89 

Stuttgart 

4 

0 

.999024 

17 

Totals 

235 

39 
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APPENDIX  C 

AUTOMATIC  ALTROUTE  AND  REST ORAL  ALGORITHM  SIZING  BACKUP 

The  following  tables  provide  the  detailed  software  sizing  for  the  altroute 
and  normalization  routines  as  presented  in  the  flow  charts  in  Report  3. 
These  routines  were  combined  into  software  modules  consistent  with  the 
sizing  effort  that  was  performed  and  presented  in  Report  2.  These  tables 
back  up  the  sizing  presented  in  Section  4. 4. 
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MAIN.  CALLING  ROUTINE-- TRUNK  SECTION 


Processing  Module 

HOL  Instructions 

Update  trunk  altroute  catalog 

20 

Select  trunk  at  top  of  altroute  catalog 

10 

Select  new  FS 

10 

Notify  users  of  trunk  to  be  pumped 

50 

Catalog  preempted  trunks  by  RP,  etc. 

10 

Direct  stations  to  PATCH  altroute 

50 

Create  TF  for  altroute  and  appropriate  cross- 
references 

30 

Delete  T  from  catalog  of  trunks  to  altroute 

5 

Failure  exit-enter  circuits  in  ckt  altroute 
catalog 

10 

Identify  circuits  that  fail  goal  station 
definition  search 

10 

Deletes  T  from  normalization  catalog 

5 

Compare  old  and  new  altroute 

15 

Delete  segments  of  old  altroute 

10 

Create  list  of  stations  bounding  failure 

20 

Flag  failed  altroute 

5 

Label  FS  as  a  failed  station;  get  new  FS 

10 

Place  ckts  on  normalization  catalog 

5 

Transfer  preemptions 

10 

Decision  logic 

25 

Calling  logic 

10 

320 
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MAIN  CALLING  ROUTINE- -CIRCUIT  SECTION 


Processing  Module 

HOL  Instructions 

Remove  cx  from  ckt  normalization  catalog 

10 

Update  cx  entry  in  altroute  catalog 

20 

Select  top  ckt  in  altroute  catalog 

5 

Sort  and  collect  ckts  with  same  FS  and  ITS 

15 

Catalog  ckts  in  ALTR  with  complete  altroute 
and  select  a  ckt 

20 

Notify  users  of  preempted  ckts 

50 

Catalog  ckts  that  are  preempted  in  normalization 
catalog  and  altroute  catalog 

20 

Direct  stations  to  PATCH  altroutes 

50 

Create  CFs  for  altroute  ckts  and  appropriate 
xrefs 

20 

Drop  altrouted  ckts  from  ckt  altroute  catalog 

5 

Update  TREE  after  altr outing  or  DUMP 

10 

Create  list  of  stations  bounding  failure 

20 

Set  flags  for  altroute  in  place  but  failed 

10 

Compare  old  and  new  altroute  for  commonality 
for  subsequent  action 

15 

Redefine  FS 

10 

Delete  cx  from  altroute  catalog 

5 

Sub-vf  ckt  breakout/catalog/etc. 

20 

Decision  logic 

25 

Calling  logic 

10 

Update  ALTR 

15 

Delete  Common  segments 

10 

Failure  exit 

10 

385 
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TRUNK  A  LTR  OUTING  ROUTINE 


Processing  Module 

HOL  Instructions 

Altroute  analysis 

70 

Update  list  of  stations 

15 

Purge  temporary  files 

10 

Enter  station  data  in  TREE  file 

15 

Search  CNF  to  find  paths 

20 

Failure  Exit 

10 

Find  lowest  cost  HITS  and  HTS 

10 

Sort  links  to  x/catalog 

15 

Catalog  trunks;  flag  spare  trunks;  order 
trunks 

10 

Test  trunk  tx  for  certain  conditions 

5 

Delete  tx  from  trunk  catalog 

10 

Open  TREE  entry  set  flags 

15 

Test  trunk  catalog  empty 

5 

Expand  altroute 

20 

Satellite  link  logic 

35 

Cost  analysis 

25 

Decision  logic 

25 

Calling  logic 

10 

Success  exit 

15 

340 
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CIRCUIT  ALTROUTING  ROUTINE 


Processing  Module 

HOL  Instructions 

Check  preplanned  altroutes 

40 

Enter  data  into  TREE  file 

15 

Search  CNF 

20 

Catalog  links /trunks 

15 

Test  tx 

10 

Add  to  list 

15 

Locate  circuits 

40 

Test  failures  for  various  alterations 

40 

Delete  files /entrys  from  catalogs 

15 

Decision  logic 

25 

Calling  logic 

15 

Failure  exit 

10 

Success  exit 

15 

Goal  station  defer 

10 

Expand  altroute 

50 

Satellite  altroute  logic 

60 

Cost  analysis 

30 

445 
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COST  CALCULATING  ROUTINE 


Processing  Module 

HOL  Instructions 

Test  x  and  ps  on  path 

20 

Add  patching  cost 

10 

Add  RP  for  all  preempted  ckts 

15 

Multiply  by  scale  factor 

20 

Sum  link  mileage 

10 

Sum  transmission  costs 

10 

Add  cost  from  x's  PS  to  the  cost  of  x 

5 

Catalog  ID  of  the  paths 

15 

Test  catalog  for  paths 

10 

Compute  euclidean  distance 

10 

Multiply  x  transmission  cost/mile 

10 

Exit  logic 

10 

Decision  logic 

20 

Modify  TREE  file 

20 

Purge  named  file 

10 

195 
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HEURISTIC  COST  CALCULATION  ROUTINE 


1 

Processing  Module 

HOL  Instructions 

Use  SCF  to  find  distance  between  x  and  A 

30 

Use  CNF  and  euclidean  distance  to  find 
shortest  x  to  a  path 

50 

Scale  mileage  and  store  as  HA  in  TREE 

40 

Find  link  transmission  costs;  add  to  HA 

40 

Decision  logic 

15 

Multiply  by  mileage  scale 

10 

Sum  mileage 

10 

Exit  logic  (with  Heuristic  cost) 

10 

205 
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GOAL  STATION  DEFINITION  ROUTINE 


Processing  Module 

HOL  Instructions 

Order  the  trunks 

20 

Order  the  end  stations 

20 

Label  OS  and  TS 

15 

Find  station  FS 

15 

Find  station  ITS 

15 

Test  #  of  stations 

10 

Test  #  of  links 

10 

List  stations  and  exit 

20 

Test  OS  -  one  link? 

15 

Redefine  FS 

20 

Failure  exit 

10 

Decision  logic 

15 

Success  exit  (with  goal  stations) 

15 

200 
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CIRCUIT  MATCHING  ROUTINE 


Processing  Module 

HOL  Instructions 

Sort  circuits  by  port  type  and  RP 

40 

Select  first  ckt 

10 

Search  for  match  precompatible  ckts 

25 

Do  for  all  PT 

10 

Delete  circuit  from  list 

15 

Decision  logic 

15 

Match  the  K  circuit 

25 

Set  flag  for  desired  circuits 

15 

155 
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NORMALIZATION  ROUTINE 


Processing  Module 

HOL  Instructions 

Enter  t  into  trunk  normalization  catalog 

15 

Delete  t  from  trunk  altroute  catalog 

10 

Tell  end  stations  t  is  in  service 

50 

Remove  preempts  t  made;  determine 
normalizing  patches  needed 

60 

Send  patching  message  for  removal  of  altroute 

50 

Update  LF  to  reflect  normalization 

15 

Check  trunk  normalization  catalog 

5 

Update  flags  in  normalization  catalog 

10 

Make  entries  in  circuit  normalization  catalog 

15 

Check  preempts /altroutes  on  c 

30 

Delete  c  from  altroute  catalog 

10 

Inform  end  stations  that  c  is  in  service 

50 

Remove  preempts  c  made;  determine 
normalization  patches 

60 

Send  patching  messages  for  removal  of 
altroute 

50 

Update  data  base  to  reflect  normalization 

25 

Check  circuit  normalization  catalog 

5 

Update  flags 

10 

Select  new  ckts 

15 

Decision  logic 

15 

Exit  logic 

10 

510 
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COMMON  FILE  HANDLING  LOGIC 


1 


Processing  Module 


HOL  Instructions 


Read  trunk  file  (TF) 
Read  fault  file  (FF) 


Read  altroute  TF 


Read  circuit  file  (CF) 


Read  TREE 


Read  ALTR 


Delete  (named)  file 


Read  altroute  CF 


Read  connectivity  file  (CNF) 
Read  station  file  (SF) 

Read  link  file  (LF) 


Read  station  coordination  file 
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